https://wiki.archlinux.org/api.php?action=feedcontributions&user=Lorenzog&feedformat=atomArchWiki - User contributions [en]2024-03-28T10:43:49ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=ArchWiki:Translation_Team_(Italiano)&diff=180905ArchWiki:Translation Team (Italiano)2012-01-28T16:07:38Z<p>Lorenzog: /* Tabella dalla 'F' alla 'O' */</p>
<hr />
<div>[[Category:Italiano]]<br />
{{i18n|ArchWiki Translation Team}}<br />
<br />
Il [http://www.archlinux.it/forum/viewtopic.php?id=8483 Team Italiano Traduzioni Arch Wiki], supportato e gestito dalla comunità del forum di [http://www.archlinux.it/ Arch Linux Italia], si prefigge lo scopo di allineare la documentazione italiana con quella inglese, tenerla costantemente aggiornata e, nel caso ve ne fosse bisogno, aiutare lo sviluppo della documentazione inglese. Gli articoli vengono scelti in base alla loro importanza ed utilità, non ultima viene considerata la ramificazione di articoli correlati ai medesimi.<br />
<br />
Questa pagina è suddivisa in tre parti principali.<br />
<br />
#Note per i Revisori (Ove vengono spiegate le principali informazioni utili su come è organizzato il nostro team ed enunciate linee guida per le traduzioni)<br />
#Bando di Traduzioni (ove si segnalano e si tiene conto delle traduzioni in corso)<br />
#Revisioni (ove gli articoli già tradotti dal nostro team vengono messi sotto osservazione, con la possibilità di [[ArchWiki Translation Team (Italiano)#Adottare un WIKI|adozione]])<br />
<br />
La natura stessa di un wiki dà la possibilità a qualsiasi utente di interagire con le pagine presenti, migliorarne il contenuto e/o aggiornarlo. Questo progetto nasce dalla volontà di creare un gruppo di utenti ben organizzato e con regole ben definite e allineate a quelle del wiki; questo per poter dare un contributo costante e di qualità a tutta la comunità italiana di Arch Linux. Invitiamo tutti gli utenti che abbiano voglia di partecipare a '''segnalare la loro disponibilità''' sul [http://www.archlinux.it/forum/viewtopic.php?id=8483 Forum di Arch Linux Italia], dove potete chiedere anche informazioni e avere risposte ai vostri dubbi.<br />
Servono sia traduttori che revisionisti, persone che controllino le traduzioni o segnalino nuove modifiche. I requisiti richiesti sono principalmente:<br />
<br />
*Serietà<br />
*Disponibilità<br />
*Attitudine ad un lavoro di squadra<br />
*Conoscenza anche scolastica dell'inglese o di altre lingue estere<br />
*Conoscenza di base del sistema Arch Linux<br />
<br />
Non bisogna preoccuparsi del tempo da dedicare, ogni aiuto è ben accetto compatibilmente con il tempo a propria disposizione.<br />
<br />
==Note per i Revisori==<br />
<br />
===Organizzazione Interna===<br />
<br />
Come più volte sottolineato un wiki on-line prevede la partecipazione libera degli utenti iscritti nel creare, modificare e aggiornare gli articoli interni. Ovviamente creare un team che possa prendersi carico della maggior parte delle pagine e seguirne lo sviluppo, nonché la sua formattazione, è sempre incentivata. Di seguito vengono esplicati alcuni criteri di come il nostro gruppo di traduzione è organizzato, agisce e collabora:<br />
<br />
* Le pagine da tradurre vengono scelte in base ad un ordine di importanza, oppure in base ad una categoria precisa, o anche in base ai vari articoli correlati a quello preso in esame.<br />
* Ogni articolo può essere proposto per la traduzione nella sua integrità, oppure scorporato nei suoi paragrafi<br />
* Scelta la pagina da tradurre/aggiornare, essa verrà inserita nel [[ArchWiki Translation Team (Italiano)#Bando di traduzione|Bando delle Traduzioni]], che elencherà tutti i paragrafi delle pagine da tradurre, o la pagina stessa. Gli utenti disponibili per la traduzione possono, in questa tabella, prenotarsi i paragrafi che più gli aggradano.<br />
* Se la pagina da tradurre è già presente in italiano verrà fatto un controllo tra i paragrafi già esistenti e quelli da tradurre, o ne verrà segnalata la necessità.<br />
* Ogni utente modificherà direttamente i propri paragrafi/pagine per cui a dato la propria disponibilità.<br />
* Le pagine della versione italiana verranno ''taggate'' con appositi template, come "Da tradurre" e/o "Out of Date" con un preciso richiamo a ad usare il wiki inglese, per informare gli utenti italiani che l'articolo potrebbe essere incompleto, si veda [[ArchWiki_Translation_Team_(Italiano)#Linee Guida|Linee Guida]] per maggiori dettagli.<br />
* A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e dei menu "Summary".<br />
* Per ogni dubbio chiedere supporto sul [http://www.archlinux.it/forum/viewtopic.php?id=8483 forum]<br />
<br />
===Linee Guida===<br />
<br />
Al fine di ottenere una corretta formattazione degli articoli ed un contenuto consono ad una documentazione on-line, è necessario cercare di osservare delle semplici linee guida, in modo da rendere omogeneo sia il contenuto di ogni articolo trattato che la navigazione tra essi. A questo scopo si consiglia di:<br />
<br />
*'''1)''' Usare un italiano corretto, evitare abbreviazioni, linguaggio da chat.<br />
<br />
*'''2)''' Scrivere sempre in forma indiretta. (ES: "aprire un terminale e digitare"... è più corretto rispetto ad " apri il terminale e digita")<br />
<br />
*'''3)''' Utilizzare '''SEMPRE''' l'anteprima nell'editing del wiki, in modo tale da avere un immediato resoconto sulla formattazione e/o sulla traduzione, in questo modo si ha la possibilità si poter correggere immediatamente eventuali errori.<br />
<br />
*'''4)''' In caso di dubbi potete chiedere liberamente nella sezione appropriata del nostro forum, evitate di fare modifiche se non siete convinti.<br />
<br />
*'''5)''' É necessario utilizzare una formattazione standard per uniformare i contenuti, di seguito vengono segnalati alcuni esempi di template da utilizzare :<br />
<br />
:;<nowiki>{{ Ic | nome_file }}</nowiki> : quando si è in presenza del nome di un file. (Es. <nowiki> {{ ic | /etc/fstab }}</nowiki>, o quando si è in presenza di un comando nel corpo del testo. Es: "Si può utilizzare <nowiki>{{ Ic | iwconfig }}</nowiki> per configurare la rete..."<br />
:;<nowiki>{{ Bc | comando}}</nowiki> : quando si è in presenza di un comando da dare da terminale o di una opzione in riferimento al kernel. Es: "Installare i driver nvidia con <nowiki>{{ Bc | # pacman -S nvidia }}</nowiki>"<br />
:;<nowiki>{{ Hc | Intestazione | contenuto }}</nowiki>: Questo template genera una visualizzazione esteticamente corretta per il contenuto di file, oppure per la visualizzazione di un comando ed il relativo output, Es: <nowiki>{{ Hc | (nome del file/comando) | (contenuto di un file o l'output di un comando, potrebbe essere necessario l'uso dei tag "nowiki" }}</nowiki><br />
:;<nowiki>{{ Keypress | tasto_funzione }}</nowiki> : Quando si è in presenza di tasti funzione o tasti di scelta rapida nel corpo del testo. Es: <nowiki>premere {{Keypress | Invio}} per continuare.</nowiki><br />
<br />
:{{Nota| La lista aggiornata per uniformare gli stili dei contenuti, comprensiva di ogni spiegazione, è reperibile in [[Help:Style (Italiano)|questo articolo]].}} <br />
<br />
*'''6)''' É necessario che i link interni agli articoli vengano fatti puntare ai corrispettivi wiki italiani già tradotti. (Es. "Arch Linux utilizza <nowiki>[[Pacman (Italiano) | pacman]]</nowiki> come gestore di pacchetti...."), lo stesso discorso vale per i tag delle categorie che si trovano ad inizio articolo (ES: <nowiki>[[Category:Hardware detection and troubleshooting (Italiano)]]</nowiki>)<br />
<br />
*'''7)''' Nel caso di traduzioni di pagine nuove appena create, ma anche in tutti gli articoli per principio di scrupolo, è necessario controllare, nell'articolo originale inglese, che non vi siano link errati di pagine italiane che puntano ancora alla pagina inglese. In questo caso bisogna andare nell'articolo originale inglese e controllare tramite la voce '''puntano a qui''' nel menu strumenti a sinistra, e controllare gli articoli italiani che puntano ad esso. Si consiglia di utilizzare la funziona ''cerca'' del proprio browser usando come parola di ricerca ''(Italiano)''.<br />
<br />
*'''8)''' Per quanto riguarda le traduzioni si ricorda che i primi revisori siete voi stessi. Di conseguenza, controllate sia l'ortografia sia che il contesto risulti leggibile e di facile comprensione. In caso di dubbi si può chiedere tranquillamente sul forum, ma si sottolinea che '''i primi revisori siete voi stessi'''. Questo poiché risulta difficile effettuare un controllo globale sui contenuti e sullo stile di ogni articolo tradotto e/o revisionato. Quindi :<br />
::*Controllate l'ortografia, spesso si può incorrere in errori di battitura, come l'errata scrittura di una parola italiana (Es. naquero senza "c" , "anceh" invece di anche").<br />
::* Controllate che il contesto risulti corretto sia nel contenuto che nella forma, a volte nella traduzione italiana bisogna invertire le parole. Es. "Quindi i Trusted User Repositories nacquero." in "Quindi nacquero i Trusted User Repositories."<br />
<br />
*'''9)''' Si consiglia di '''commentare sempre''' le modifiche si effettuano. Questa procedura è molto utile per capire immediatamente in cosa consistono le modifiche effettuate, utile per la consultazione da parte di altri utenti e anche di voi stessi; ovviamente in caso di grossi interventi come una traduzione completa o parziale di un articolo si può essere dispersivi sul commento (es: traduzione e/o allineamento paragrafo). Inoltre si ricorda di spuntare la casella ''questa è una modifica minore'' in caso di piccoli interventi, quali correzioni di link errati, o di ortografia/stili. Si rammenta che il wiki è un progetto aperto e il nostro team non ha l'esclusiva sulle pagine da trattare, prendere l'abitudine di commentare tutti gli interventi è molto utile sia a voi stessi che ad eventuali altri utenti e/o revisori che controllano la pagina.<br />
<br />
Di seguito si presentano alcuni template da inserire ad inizio articolo per segnalare che la pagina è in fase di lavorazione:<br />
<br />
;Nel caso di Aggiornamenti e Revisioni : <nowiki> {{out_of_date}} {{Attenzione|Questa pagina è in fase di revisione e potrebbe non essere aggiornata. Seguite per ora le istruzioni della versione inglese.}} </nowiki><br />
<br />
;Nel caso di traduzioni in corso e/o pagine create:<nowiki>{{translateme}} {{Attenzione|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}</nowiki><br />
<br />
=== Fonti Utili===<br />
<br />
Di seguito vengono elencate alcune fonti utili per effettuare una buona traduzione e/o per avere informazioni su come funziona un wiki.<br />
<br />
* Strumenti utili per i traduttori <sup>[http://www.archlinux.it/forum/viewtopic.php?id=1087]</sup><br />
* Regole per una buona traduzione <sup>[http://tp.linux.it/buona_traduzione.html]</sup><br />
* Che cos'è un wiki <sup>[http://wiki.archlinux.org/index.php/AboutWiki_(Italiano)]</sup><br />
* Tutorial per usare il wiki <sup>[http://wiki.archlinux.org/index.php/ArchWiki_Tutorial_(Italiano)]</sup><br />
<br />
==Bando di traduzione==<br />
<br />
In questa sezione vengono ubicate le nuove pagine da tradurre, ed è presente una tabella ove si prenotano i vari paragrafi o l'articolo nella sua integrità. Nella prima voce della tabella vengono inserite le pagine e/o i paragrafi da tradurre. La seconda voce "''Note''" serve a dare un avviso ai potenziali revisori nel caso ci siano accorgimenti da intraprendere prima di effettuare la traduzione, questo spazio è riservato anche a note personali dei traduttori che '''sono tenuti a segnalare la data di ultimo allineamento''' con il wiki inglese.<br />
La terza voce della tabella è riservata agli utenti che vogliono prendersi carico dell'articolo in questione, qui bisogna immettere il proprio nome utente in modo da segnalare chi si sta occupando della revisione. L'ultima voce della tabella serve a descrivere, a cura dei revisori, l'andamento della traduzione che può essere:<br />
*'''In Corso''' - Quando iniziate la traduzione.<br />
*'''Verifica''' - In caso di traduzione ultimata ma volete ancora verificarne il contenuto e/o aspettate un chiarimento da un altro utente.<br />
*'''Completa''' - In caso di traduzione ultimata. <br />
L'apposizione dello stato "''Completa''" fa sì che il responsabile di turno sposti il wiki tradotto completamente nella sezione [[Traduzioni#Revisioni|Revisioni]], '''non sta al traduttore prendersi carico di questo onere'''. A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e del sommario, nonché della traduzione dei link relativi alle categorie.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina - Paragrafi<br />
! scope="col" width="40%" | Note<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
|-<br />
| [[Archiso (Italiano)]]<br />
| Pagina creata il 10 gennaio<br />
|<br />
|<br />
|-<br />
| [[Larch (Italiano)]]<br />
| Pagina creata il 10 gennaio<br />
|<br />
|<br />
|-<br />
|[[Custom Kernel Compilation with ABS (Italiano)]]<br />
|Pagina da riallineare<br />
|<br />
|<br />
|-<br />
|[[LVM (Italiano)]]<br />
|Pagina da riallineare<br />
|Maveloth<br />
|in corso<br />
|-<br />
| [[Improve Pacman Performance (Italiano)]]<br />
| Pagina creata il 25-10-2011 <br />
| <br />
|<br />
|-<br />
| [[Plasma (Italiano)]]<br />
| Pagina allineata il 27/12/2010<br />
| Trapanator<br />
| In corso<br />
|-<br />
| [[Systemd (Italiano)]]<br />
|<br />
|ambro<br />
|In corso<br />
|-<br />
|[[System Encryption with eCryptfs (Italiano)]]<br />
|Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[Python Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
| [[Eclipse (Italiano)]]<br />
| Pagina da tradurre allineata il 09/10/2011<br />
|<br />
|<br />
|-<br />
| [[Ruby Gem Package Guidelines (Italiano)]]<br />
| Pagina da riallineare<br />
|<br />
|<br />
|-<br />
|[[GTK%2B_(Italiano)|GTK+ (Italiano)]]<br />
|Pagina da tradurre<br />
|Ninquitassar<br />
|In corso<br />
|-<br />
| [[User:Maveloth#Pagine_con_riferimenti_a_kernel26]]<br />
| Lista delle pagine che utilizzano ancora la dicitura al kernel26 invece che a '''linux'''<br />
|<br />
|<br />
|-<br />
| [[Partitioning (Italiano)]]<br />
| Pagina con ultima revisione 2011-10-12<br />
| Veleno77<br />
|<br />
|}<br />
<br />
{{nota| É importante segnare la data di ultimo allineamento con l'articolo inglese, questo serve a tenerne traccia nel tempo.}}<br />
<br />
===Pagine in Sospeso===<br />
<br />
In questa sotto-sezione trovano posto quelle pagine che pur se prese in considerazione, sono state taggate in vario modo, magari come "merging", "stub" etc... e in teoria si attende che la versione inglese subisca una revisione definitiva. Nella tabella seguente le pagine segnalate come da "'''Allineare'''" indicano quelle pagine completamente da revisionare , e da allineare alla versione inglese. Vengono spostate in questa tabella anche pagine in sospeso per varia natura, sono comunque articoli che in futuro verranno allineati e spostati nel [[Traduzioni#Bando di traduzione|Bando di traduzione]] quando disponibili.<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="35%" | Motivazione<br />
! scope="col" width="30%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[WindowLab]]<br />
| Pagina segnalata come '''Stub'''<br />
|<br />
|-align="center"<br />
| [[Kernel Module Package Guidelines (Italiano)]]<br />
| Pagina segnalata come '''Stub'''<br />
| 2010-12-30<br />
|-<br />
|}<br />
<br />
=Revisioni=<br />
In questa sezione verranno messi i vari articoli del wiki già tradotti precedentemente dal nostro staff, verrà inserita la data di ultima revisione e eventualmente il ''nome utente'' e lo ''stato'' di revisione in caso si stia procedendo al riallineamento della pagina rispetto al wiki inglese. '''Attenzione le date sono in stile anglosassone ovvero : yyyy-mm-gg (ES. 2011-01-30)'''. Le revisioni degli articoli non seguono una procedura temporale specifica, ognuno è libero di controllare lo stato di allineamento di un wiki già trattato in precedenza, oppure può procedere all' '''adozione''' del medesimo.<br />
<br />
== Adottare un WIKI==<br />
È possibile '''Adottare''' un wiki a vostra scelta, l'adozione di un wiki comporta la piena responsabilità della revisione e allineamento continuo della pagina che si prende in custodia. Per procedere all'adozione si consiglia di:<br />
<br />
* Controllare le [https://wiki.archlinux.org/index.php/Special:Preferences preferenze del vostro profilo] sul wiki e selezionare l'opzione (disattivata di default) per essere avvisati via e-mail dei cambiamenti nelle pagine da voi messe sotto osservazione. In particolare devono essere spuntate tutte le seguenti opzioni : <br />
::Segnalami via e-mail le modifiche alle pagine osservate <br\> Segnalami via e-mail le modifiche alla mia pagina di discussione <br\> Segnalami via e-mail anche le modifiche minori<br />
*Aggiungere tra i propri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] la pagina che si vuole adottare, accessibile nel menu del proprio profilo, è possibile aggiungere le pagine cliccando su [https://wiki.archlinux.org/index.php/Special:Watchlist/raw Modifica la lista in formato testo] (fate attenzione all'ortografia e in caso di più pagine aggiungetele una sotto l'altra)<br />
<br />
Dalla pagina [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] e possibile seguire tutte le variazioni delle pagine da noi adottate in un unico resoconto. Se avete seguito attentamente la procedura indicata, verrete contattati via email nel caso di cambiamenti anche minori delle pagine adottate.<br />
<br />
{{nota|Nella email che vi viene mandata come avviso, vi sarà anche un link diretto alla Diff della cronologia dell'articolo preso in esame (è il secondo link in ordine). '''Fate attenzione''', non sempre le modifiche mostrate sono complete, soprattutto nel caso di molte modifiche ravvicinate. É preferibile, una volta ricevuto l'avviso di revisione, procedere con un Diff personalizzato, impostando una data antecedente all'ultima revisione nella scheda ''cronologia''. Un'altra peculiarità osservata, è che visitando le pagine senza aver effettuato il login, dopo aver ricevuto le email, o modificandole in un momento successivo, il sistema smette di inviare le notifiche, in quanto considera l'utente non più interessato a riceverle. Meglio quindi, per sicurezza, dare una controllata "manuale" alle proprie pagine ogni tanto.}}<br />
<br />
* Atom feeds: è anche possibile ricevere notifiche sull'attività di tutte le pagine wiki aggiungendo il seguente link [https://wiki.archlinux.org/index.php?title=Special:RecentChanges&feed=atom Archwiki Atom feed] al proprio lettore Feed preferito (akregator, liferea, ecc). <br />
:{{suggerimento|Può risultare utile avere un ''feed Atom personalizzato'' per le sole pagine che state seguendo. Per ottenerlo basta andare nella pagina dei vostri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] (bisogna aver effettuato il login al wiki per raggiungerlo), successivamente seguire il link '''Feed Atom''' sulla sinistra nel menu ''strumenti'' e aggiungerlo al proprio lettore Feed.}}<br />
<br />
É possibile che un ''Supervisore'' potrebbe controllare lo stato di aggiornamento dei wiki adottati, e nel caso si riscontrassero delle inadempienze, verrà segnalato ai rispettivi utenti di procedere al riallineamento. <br />
<br />
<br />
==Tabella riassuntiva dei Wiki Revisionati e Adottati==<br />
<br />
Vengono presentati tutti gli articoli tradotti dal nostro team e impaginati in tre tabelle in ordine alfabetico <sup>([[ArchWiki_Translation_Team_(Italiano)#Tabella dalla 'A' alla 'E'|A-E]]),([[ArchWiki_Translation_Team_(Italiano)#Tabella dalla 'F' alla 'O'|F-O]]),([[ArchWiki_Translation_Team_(Italiano)#Tabella dalla 'P' alla 'Z'|P-Z]])</sup>, per una semplice e più rapida consultazione.<br />
La tabella contiene cinque voci:<br />
<br />
# '''Pagina''' - Viene inserito il link alla pagina italiana trattata.<br />
# '''Ultima revisione''' - Viene inserita la data di ultima revisione e/o riallineamento. La data è in stile anglosassone: yyyy-mm-gg.<br />
# '''Revisore''' - L'utente che adotta la pagine immette qui il suo nome utente.<br />
# '''Cedibile''' - L'utente che ha adottato la pagina può, apponendo una '''X''' o la parola '''Cedibile''', rendere pubblico che decide di lasciarne l'adozione. Ad esempio se non si ha più tempo da dedicare alla traduzione e/o altro.<br />
# '''Note''' - Spazio riservato a note personali dell'utente che ha in adozione l'articolo e/o ad appunti di un supervisore.<br />
<br />
Le prime quattro voci contengono un link ''rapido'' di consultazione che effettua un ordine alfabetico nella colonna medesima, utile ad esempio per controllare immediatamente in base alle date gli articoli più datati.<br />
<br />
===Tabella dalla 'A' alla 'E'===<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Cedibile<br />
! class="unsortable" width="50%" | Note<br />
|-align="center"<br />
| [[Acpid (Italiano)]]<br />
| 2012-01-06<br />
| veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture (Italiano)]]<br />
| 2012-01-28<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture/Example Configurations (Italiano)]]<br />
| 2012-01-19<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Allow Users to Shutdown (Italiano)]]<br />
| 2012-01-21<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Amarok 2 (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Android Notifier (Italiano)]]<br />
| 2012-01-19<br />
| Maveloth<br />
| <br />
|<br />
|-align="center"<br />
| [[Arch64 FAQ (Italiano)]]<br />
| 2012-01-23<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Arch Boot Process (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Arch Build System (Italiano)]]<br />
| 2012-01-28<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Arch Linux (Italiano)]]<br />
| 2012-01-19<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Arch Packaging Standards (Italiano)]]<br />
| 2012-01-19<br />
| Toketin<br />
|<br />
| Da controllare la fromattazzione Html [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Arch User Repository (Italiano)]]<br />
| 2012-01-19<br />
| Morbin<br />
|<br />
|<br />
|-align="center"<br />
| [[Arch wine PKGBUILD guidelines (Italiano)]]<br />
| 2012-01-19<br />
| maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[ATI (Italiano)]]<br />
| 2012-01-28<br />
| 4javier<br />
|<br />
| <br />
|-align="center"<br />
| [[ATI Catalyst (Italiano)]]<br />
| 2012-01-27<br />
| umby213<br />
| <br />
| <br />
|-align="center"<br />
| [[Autofs (Italiano)]]<br />
| 2012-01-19<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Automatic login to virtual console (Italiano)]]<br />
| 2012-01-14<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Awesome3 (Italiano)]]<br />
| 2011-01-06<br />
| Delcaran <br />
|<br />
| '''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Bash (Italiano)]]<br />
| 2011-12-05 <br />
| Veleno77<br />
|<br />
|'''presa in consegna''' [[User:Veleno77|Veleno]] 09:04, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Beginners' Guide (Italiano)]]<br />
| 2012-01-17<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Bluetooth (Italiano)]]<br />
| 2012-01-21<br />
| icetux <br />
|<br />
|<br />
|-align="center"<br />
| [[Boot Debugging (Italiano)]]<br />
| 2012-01-19 <br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Bumblebee (Italiano)]]<br />
| 2011-10-17 <br />
| Veleno77<br />
|<br />
|'''presa in consegna''' [[User:Veleno77|Veleno]] 09:04, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Burg (Italiano)]]<br />
| 2011-05-18<br />
| Toketin <br />
|<br />
|'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[CD Burning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Clyde (Italiano)]]<br />
| 2012-01-19<br />
| Berseker<br />
| '''X'''<br />
|<br />
|-align="center"<br />
| [[Codecs (Italiano)]]<br />
| 2012-01-13<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Color Bash Prompt (Italiano)]]<br />
| 2011-10-19<br />
| Veleno77<br />
|<br />
|'''presa in consegna''' [[User:Veleno77|Veleno]] 09:04, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Common Applications (Italiano)]]<br />
| 2011-12-16<br />
| Veleno77<br />
|<br />
|In fase di revisione, un riassunto è disponibile a [[Talk:Common Applications#Summary of related changes]]<br />
|-align="center"<br />
| [[Compiz (Italiano)]]<br />
| 2012-01-19<br />
| Berseker<br />
| '''X'''<br />
|<br />
|-align="center"<br />
| [[Compiz Troubleshooting (Italiano)]]<br />
| 2012-01-19<br />
| Debbio<br />
| '''X'''<br />
|<br />
|-align="center"<br />
| [[Conky (Italiano)]]<br />
| 2011-09-21<br />
| Ninquitassar<br />
|<br />
|'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Configuring Network (Italiano)]]<br />
| 2012-01-16<br />
| icetux <br />
|<br />
|<br />
|-align="center"<br />
| [[Connman (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Console Mouse Support (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|--align="center"<br />
| [[CPU Frequency Scaling (Italiano)]]<br />
| 2012-01-07<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Creating Packages (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[CUPS (Italiano)]]<br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Cwm (Italiano)]]<br />
| 2012-01-19<br />
| Debbio<br />
| '''X'''<br />
| <br />
|-align="center"<br />
| [[Daemon (Italiano)]]<br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|'''Da Ri-allineare''' [[User:Veleno77|Veleno]] 11:17, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Desktop Environment (Italiano)]]<br />
| 2012-01-10<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Digital Cameras (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Disk Cloning (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Display Manager (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[Downgrading Packages (Italiano)]]<br />
| 2012-01-19<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Dropbox (Italiano)]]<br />
| 2012-01-18<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[E17 (Italiano)]]<br />
| 2012-01-19<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Eclipse plugin package guidelines (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Enlightenment (Italiano)]]<br />
| 2012-01-19<br />
| Veleno77 <br />
|<br />
|<br />
|-align="center"<br />
| [[Evilwm (Italiano)]]<br />
| 2012-01-19<br />
| Debbio <br />
| '''X'''<br />
| <br />
|-align="center"<br />
| [[Execute on usb insert (Italiano)]]<br />
| 2012-01-19<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Ext3 (Italiano)]]<br />
| 2012-01-19<br />
| Morbin<br />
|<br />
|<br />
|-align="center"<br />
| [[Ext4 (Italiano)]]<br />
| 2012-01-19<br />
| Morbin<br />
|<br />
|<br />
|-<br />
|}<br />
<br />
===Tabella dalla 'F' alla 'O'===<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Cedibile<br />
! class="unsortable" width="50%" | Note<br />
|-align="center"<br />
| [[Fan Speed Control (Italiano)]]<br />
| 2012-01-26<br />
| <br />
|<br />
|-align="center"<br />
| [[Fbsplash (Italiano)]]<br />
| 2012-01-19<br />
| Cylon<br />
|<br />
| '''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Feh (Italiano)]]<br />
| 2012-01-21<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Filesystem Hierarchy Standard (Italiano)]]<br />
| 2012-01-19<br />
| Morbin<br />
|<br />
| Versione inglese segnalata come "Out of Date"<br />
|-align="center"<br />
| [[Firewalls (Italiano)]]<br />
| 2012-01-19<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox (Italiano)]]<br />
| 2012-01-21<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Fluxbox Style Guide (Italiano)]]<br />
| 2012-01-19<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Fonts (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Font Configuration (Italiano)]]<br />
| 2012-01-19<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Fstab (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[FVWM (Italiano)]]<br />
| 2011-11-05<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[General Recommendations (Italiano)]]<br />
| 2012-01-19<br />
| asa <br />
|<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Getting Involved (Italiano)]]<br />
| 2012-01-28<br />
| kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[GNOME (Italiano)]]<br />
| 2011-12-3<br />
| TheREAL1<br />
|<br />
| Grossi cambiamenti in arrivo, seguire [[Talk:GNOME]] e [[Talk:GNOME Tips]]<br />
|-align="center"<br />
| [[Gnome 2.28 Changes (Italiano)]]<br />
| 2012-01-19<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome package guidelines (Italiano)]]<br />
| 2012-01-22<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Gnome Tips (Italiano)]]<br />
| 2011-03-22<br />
| Debbio<br />
| '''X'''<br />
| Grossi cambiamenti in arrivo, seguire [[Talk:GNOME]] e [[Talk:GNOME Tips]]<br />
|-align="center"<br />
| [[GRUB (Italiano)]]<br />
| 2012-01-19<br />
| Morbin<br />
|<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[GRUB2 (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
| <br />
|-align="center"<br />
| [[Haskell package guidelines (Italiano)]]<br />
| 2012-01-19<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Help:Style (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[IceWM (Italiano)]]<br />
| 2012-01-15<br />
| umby213<br />
| <br />
| Versione inglese segnata come ''poorly written''<br />
|-align="center"<br />
| [[init and inittab (Italiano)]]<br />
| 2012-01-20<br />
| umby213<br />
|<br />
| <br />
|-align="center"<br />
| [[Installing Arch Linux on a USB key (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Install from Existing Linux (Italiano)]]<br />
| 2011-10-01<br />
| Stele<br />
|<br />
|'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Install from SSH (Italiano)]]<br />
| 2012-01-19<br />
| Stele<br />
|<br />
|<br />
|-align="center"<br />
| [[Install from a USB flash drive (Italiano)]]<br />
| 2011-04-19<br />
| Debbio<br />
| '''X'''<br />
|presa in consegna [[User:Umby213|Umby213]] 08:14, 28 January 2012 (EST)<br />
|-align="center"<br />
| [[Intel (Italiano)]]<br />
| 2012-01-07<br />
| Veleno77<br />
|<br />
|<br />
|--align="center"<br />
| [[Iptables (Italiano)]]<br />
| 2012-01-27<br />
|<br />
|<br />
| <br />
|-align="center"<br />
| [[Java (Italiano)]]<br />
| 2012-01-19<br />
| thewall<br />
|<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[Java Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[JWM (Italiano)]]<br />
| 2012-01-19<br />
| Debbio<br />
| '''X'''<br />
|<br />
|-align="center"<br />
| [[KDE (Italiano)]]<br />
| 2012-01-21<br />
| Debbio<br />
| '''X'''<br />
| '''Da riallineare''' ultima verifica 19 aprile 2011 [[User:Veleno77|Veleno]] 09:04, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[KDM (Italiano)]]<br />
| 2012-01-26<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Kernel modules (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[KVM (Italiano)]]<br />
| 2011-03-11<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[LAMP (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Laptop (Italiano)]]<br />
| 2011-12-07<br />
| veleno77<br />
| <br />
|<br />
|-align="center"<br />
| [[Laptop Mode Tools (Italiano)]]<br />
| 2011-11-28<br />
| veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Lisp Package Guidelines (Italiano)]]<br />
| 2012-01-19<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[LXDE (Italiano)]]<br />
| 2011-01-06<br />
| xaber<br />
|<br />
| La pagina non è allineata alla versione inglese. [[User:Veleno77|Veleno]] 07:50, 21 October 2011 (EDT)<br />
|-align="center"<br />
| [[Main Page (Italiano)]]<br />
| 2012-01-28<br />
| kynikos<br />
|<br />
| <br />
|-align="center"<br />
| [[Makepkg (Italiano)]]<br />
| 2012-01-19<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Master Boot Record (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Mkinitcpio (Italiano)]]<br />
| 2011-09-28<br />
| Morbin <br />
|<br />
| '''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Mirrors (Italiano)]]<br />
| 2012-01-21<br />
| Morbin<br />
|<br />
|'''da aggiornare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-align="center"<br />
| [[MySQL (Italiano)]]<br />
| 2012-01-26<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[MPlayer (Italiano)]]<br />
| 2012-01-18<br />
| Umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Mpd (Italiano)]]<br />
| 2011-01-08<br />
| Delcaran<br />
|<br />
|'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Mutt (Italiano)]]<br />
| 2011-10-28<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Namcap (Italiano)]]<br />
| 2012-01-19<br />
| thewall<br />
|<br />
|<br />
|-align="center"<br />
| [[Nano (Italiano)]]<br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Ncmpcpp (Italiano)]]<br />
| 2012-01-14<br />
| Ninquitassar<br />
| <br />
| <br />
|-align="center"<br />
| [[Netcfg (Italiano)]]<br />
| 2012-01-19<br />
| Toketin<br />
|<br />
|'''da allineare'''<br />
|-align="center"<br />
| [[NetworkManager (Italiano)]]<br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|'''DA ALLINEARE''' [[User:Umby213|Umby213]] 14:20, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Network Time Protocol daemon (Italiano)]]<br />
| 2012-01-21<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[NFS (Italiano)]]<br />
| 2012-01-27<br />
|<br />
|<br />
| <br />
|-align="center"<br />
| [[Nouveau (Italiano)]]<br />
| 2012-01-14<br />
| Veleno77<br />
| <br />
| <br />
|-align="center"<br />
| [[NTFS-3G (Italiano)]]<br />
| 2012-01-19<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[NVIDIA (Italiano)]]<br />
| 2012-01-17<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[OCaml Package Guidelines (Italiano)]]<br />
| 2012-01-28<br />
| kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Official Repositories (Italiano)]]<br />
| 2012-01-16<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Openbox (Italiano)]]<br />
| 2012-01-23<br />
| 4javier <br />
|<br />
|<br />
|-align="center"<br />
| [[Openbox Themes and Apps (Italiano)]]<br />
| 2012-02-23<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[OpenNTPD (Italiano)]]<br />
| 2012-01-19<br />
| Toketin <br />
|<br />
|<br />
|-align="center"<br />
| [[OSS (Italiano)]]<br />
| 2012-01-19<br />
| asa<br />
|<br />
|'''da allineare''' [[User:Umby213|Umby213]] 15:36, 26 January 2012 (EST)<br />
|-<br />
|}<br />
<br />
===Tabella dalla 'P' alla 'Z'===<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! Pagina<br />
! Ultima revisione<br />
! Revisore<br />
! Cedibile<br />
! class="unsortable" width="50%" | Note<br />
|-align="center"<br />
| [[Pacman (Italiano)]]<br />
| 2011-12-06<br />
| Morbin<br />
|<br />
| '''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Pacman-key (Italiano)]]<br />
| 2012-01-19<br />
| Ninquitassar<br />
|<br />
| <br />
|-align="center"<br />
| [[Password Recovery (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[Pawm (Italiano)]]<br />
| 2011-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[PekWM (Italiano)]]<br />
| 2011-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Perl Package Guidelines (Italiano)]]<br />
| 2011-09-23<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Persistent block device naming (Italiano)]]<br />
| 2011-12-08<br />
| Maveloth<br />
|<br />
| <br />
|-align="center"<br />
| [[PKGBUILD (Italiano)]]<br />
| 2012-01-25<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Pm-utils (Italiano)]]<br />
| 2012-01-23<br />
| Veleno77<br />
|<br />
|<br />
|-align="center"<br />
| [[Powerpill (Italiano)]]<br />
| 2012-01-28<br />
| kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Privoxy (Italiano)]]<br />
| 2011-09-08<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[PulseAudio (Italiano)]]<br />
| 2011-10-02<br />
| Hilinus <br />
|<br />
|<br />
|-align="center"<br />
| [[Rc.conf (Italiano)]]<br />
| 2010-12-10<br />
| 4javier<br />
|<br />
| '''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Readline (Italiano)]]<br />
| 2011-10-13<br />
| <br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Resolv.conf (Italiano)]]<br />
| 2011-11-02<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Samba (Italiano)]]<br />
| 2011-11-02<br />
| Maveloth <br />
|<br />
|<br />
|-align="center"<br />
| [[Secure Shell (Italiano)]]<br />
| 2011-12-08<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Shutdown Pressing Power Button (Italiano)]]<br />
| 2011-10-20<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[SLiM (Italiano)]]<br />
| 2012-01-16<br />
| umby213<br />
| <br />
|<br />
|-align="center"<br />
| [[Solid State Drives (Italiano)]]<br />
| 2011-09-05<br />
|<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Sound (Italiano)]]<br />
| 2011-02-21<br />
| asa<br />
|<br />
|<br />
|-align="center"<br />
| [[Sshfs (Italiano)]]<br />
| 2011-11-13<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[SSH Keys (Italiano)]]<br />
| 2011-12-17<br />
| Kynikos<br />
|<br />
| '''Da riallineare''' --[[User:Kynikos|Kynikos]] 09:50, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Start X at Boot (Italiano)]]<br />
| 2011-09-20<br />
| Hilinus<br />
|<br />
|<br />
|-align="center"<br />
| [[Synergy (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
| <br />
|-align="center"<br />
| [[Sudo (Italiano)]]<br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|<br />
|-align="center"<br />
| [[Sugar (Italiano)]]<br />
| 2011-11-05<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[The Arch Way (Italiano)]]<br />
| 2011-07-16<br />
| icetux<br />
|<br />
|<br />
|-align="center"<br />
| [[Thunar (Italiano)]]<br />
| 2012-01-18<br />
| umby213<br />
|<br />
|<br />
|-align="center"<br />
| [[Touchpad Synaptics (Italiano)]]<br />
| 2011-04-19<br />
| Debbio<br />
| '''X'''<br />
| '''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Trayfreq (Italiano)]]<br />
| 2011-10-09<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[TuPac (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
| <br />
|-align="center"<br />
| [[TuxOnIce (Italiano)]]<br />
| 2011-10-12<br />
| <br />
|<br />
| '''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Twm (Italiano)]]<br />
| 2011-11-21<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Udev (Italiano)]]<br />
| 2011-12-08<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Uniform Look for QT and GTK Applications (Italiano)]]<br />
| 2011-06-02<br />
| Ninquitassar<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Users and Groups (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Using Powerpill with AIF (Italiano)]]<br />
| 2012-01-28<br />
| kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Uvesafb (Italiano)]]<br />
| 2011-10-17<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[VCS PKGBUILD Guidelines (Italiano)]]<br />
| 2011-03-17<br />
| 4javier<br />
|<br />
|<br />
|-align="center"<br />
| [[Very Secure FTP Daemon (Italiano)]]<br />
| 2011-09-28<br />
|<br />
|<br />
|<br />
|-align="center"<br />
| [[Vim (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[Vim/.vimrc (Italiano)]]<br />
| 2012-01-28<br />
| Kynikos<br />
|<br />
|<br />
|-align="center"<br />
| [[VirtualBox (Italiano)]]<br />
| 2011-03-21<br />
| ant84<br />
|<br />
|<br />
|-align="center"<br />
| [[VMware (Italiano)]]<br />
| 2011-09-29<br />
|<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Webmin (Italiano)]]<br />
| 2011-08-10<br />
| Maveloth <br />
|<br />
|<br />
|-align="center"<br />
| [[Wicd (Italiano)]]<br />
| 2011-12-08<br />
| Maveloth<br />
|<br />
|<br />
|-align="center"<br />
| [[Window Manager (Italiano)]]<br />
| 2011-04-19<br />
| Debbio<br />
| '''X'''<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Window Maker (Italiano)]]<br />
| 2011-12-16<br />
| Veleno77<br />
|<br />
| <br />
|-align="center"<br />
| [[Wireless Setup (Italiano)]] <br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[WPA Supplicant (Italiano)]]<br />
| 2011-09-28<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[X11 Cursors (Italiano)]]<br />
| 2011-10-11<br />
| <br />
|<br />
|<br />
|-align="center"<br />
| [[Xfce (Italiano)]]<br />
| 2011-04-19<br />
| Debbio<br />
| '''X'''<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xinitrc (Italiano)]]<br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xorg (Italiano)]] <br />
| 2011-12-06<br />
| Morbin<br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-align="center"<br />
| [[Xscreensaver (Italiano)]] <br />
| 2011-10-13<br />
| <br />
|<br />
|'''Da riallineare''' --[[User:Ninquitassar|Ninquitassar]] 07:46, 19 January 2012 (EST)<br />
|-<br />
|}<br />
<br />
=Staff Tecnico=<br />
In questo spazio ogni utente può inserire o cancellare il proprio nome se lo desidera.<br />
<br />
* '''Responsabili del progetto'''<br />
:# [[User:Veleno77|Veleno77]] - Supervisore<br />
:# [[User:Kynikos|Kynikos]]<br />
:# [[User:4javier|4javier]]<br />
:# [[User:morbin|morbin]]<br />
<br />
* '''Traduttori'''<br />
:# [[User:veleno77 |veleno77 ]]<br />
:# [[User:debbio|debbio]]<br />
:# [[User:4javier|4javier]]<br />
:# [[User:morbin|morbin]]<br />
:# [[User:lolloso|lolloso]]<br />
:# [[User:Simandr|Simandr]]<br />
:# [[User:oceans11|oceans11]]<br />
:# [[User:toketin|toketin]]<br />
:# [[User:Berseker|Berseker]]<br />
:# [[User:Gilmo|Gilmo]]<br />
:# [[User:Trapanator|Trapanator]]<br />
:# [[User:Pappe|Pappe]]<br />
:# [[User:Linux@to|Linux@to]]<br />
:# [[User:Ossk|Ossk]]<br />
:# [[User:Gianfrix|Gianfrix]]<br />
:# [[User:Maveloth|Maveloth]]<br />
:# [[User:icetux|icetux]]<br />
:# [[User:Ahel|Ahel]]<br />
:# [[User:Wolfanger|Wolfanger]]<br />
:# [[User:Asa|Asa]]<br />
:# [[User:TheKaspa|TheKaspa]]<br />
:# [[User:thewall|thewall]]<br />
:# [[User:lorenzog|lorenzog]]<br />
:# [[User:Kynikos|Kynikos]]<br />
:# [[User:Hilinus|Hilinus]]<br />
:# [[User:ant84|ant84]]<br />
:# [[User:TheREAL1|TheREAL1]]<br />
:# [[User:SirX|SirX]]<br />
:# [[User:Cylon|Cylon]]<br />
:# [[User:Ninquitassar|Ninquitassar]]<br />
:# [[User:umby213|Umby213]]<br />
<br />
=Ulteriori informazioni e supporto=<br />
Per informazioni e delucidazioni sul progetto di traduzione e mantenimento wiki italiano, consultare il [http://www.archlinux.it/forum/viewtopic.php?id=8483 forum italiano]</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=SysVinit_(Italiano)&diff=161206SysVinit (Italiano)2011-09-21T14:46:57Z<p>Lorenzog: tolto tag translateme</p>
<hr />
<div>[[Category:Boot process (Italiano)]]<br />
[[Category:Daemons and system services (Italiano)]]<br />
[[Category:System administration (Italiano)]]<br />
[[Category:System recovery (Italiano)]]<br />
{{i18n|Init and inittab}}<br />
<br />
'''init''' è il primo processo che viene eseguito una volta che il kernel Linux è stato caricato. Il programma di init di default usato da Arch è {{Filename|/sbin/init}} ed è fortniro dal pacchetto {{Package Official|sysvinit}}. La parola {{Codeline|'''init'''}} in questo articolo si riferirà a {{Codeline|sysvinit}}.<br />
<br />
'''inittab''' è il file di configurazione dell'avvio per {{Codeline|init}} e si trova in {{Filename|/etc}}. Esso contiene le cartelle per {{Codeline|init}} o quali programmi o script eseguire quando si entra in uno specifico runlervel.<br />
<br />
{{Tip|Consultare {{Codeline|man 5 inittab}} e {{Codeline|man 8 init}} per una descrizione più completa e formale.}}<br />
<br />
{{Tip|Sebbene Arch utilizzi {{Codeline|init}}, la maggiorparte del lavoro viene delegato ai [[#Principali Script di Boot|principali script di boot]]. Questo articolo traterà principalmente {{Codeline|init}} ed {{Filename|inittab}}; per maggiori informazioni sul processo di avvio di Arch consultare [[Arch Boot Process (Italiano)|Arch Boot Process]].}}<br />
<br />
==Parametri del kernel correlati==<br />
<br />
Per utilizzare un altro programma di {{Codeline|init}} (es. [[systemd (Italiano)|systemd]]), aggiungere {{Codeline|'''init<nowiki>=</nowiki>/bin/systemd'''}} o simile alla riga del kernel in [[GRUB (Italiano)|GRUB]]. Per cambiare il runlevel in cui il sistema effettua il boot, semplicemente aggiungere il runlevel desiderato {{Codeline|'''n'''}} alla riga del kernel. Un comune uso di questo può essere trovato in [[Start_X_at_boot (Italiano)#/etc/inittab|qeusto articolo]].<br />
{{Nota|Se si utilizza un programma di init diverso da {{Codeline|sysvinit}}, il parametro del runlevel potrebbe essere ignorato.}}<br />
<br />
==Panoramica di init e inittab==<br />
<br />
{{Codeline|init}} è sempre il processso con PID 1 ed all'infuori della gestione dell'area di swap, è il processo genitore per '''tutti''' gli altri processi. Può essere notato meglio il ruolo che svolge init nella gerarchia dei processi del proprio sistema usando il comando {{Codeline|pstree}}:<br />
<br />
{{Command|pstree -Ap|<nowiki><br />
init(1)-+-acpid(3432)<br />
|-crond(3423)<br />
|-dbus-daemon(3469)<br />
|-gpm(3485)<br />
|-mylogin(3536)<br />
|-ngetty(3535)---login(3954)---zsh(4043)---pstree(4326)<br />
|-polkitd(4033)---{polkitd}(4035)<br />
|-syslog-ng(3413)---syslog-ng(3414)<br />
`-udevd(643)-+-udevd(3194)<br />
`-udevd(3218)<br />
</nowiki>}}<br />
<br />
Oltre alle comuni inizializzazioni di sistema (come suggerisce il nome), {{Codeline|init}} si occupa del riavvio, dello spengimento e del avvio in recovery mode (single-user-mode). Per supportare tutto questo il file {{Filename|inittab}} raggruppa queste modalità in diversi '''runlevel'''. I runlevel usati da Arch sono 0 per lo spengimento, 1 (oppure S che è un suo alias) per il single-user-mode, 3 per il normale boot (multi-user-mode), 5 per [[Xorg (Italiano)|X]] e 6 per il riavvio. Altre distribuzioni possono adottare altre convenzioni, ma l'uso dei runlevel 0, 1 e 6 è universale.<br />
<br />
<br />
Al momento dell'esecuzione, {{Codeline|init}} scansiona {{Filename|inittab}} ed effettua le appropriate azioni. Una voce di {{Filename|inittab}} ha questa forma:<br />
<br />
<pre><br />
id:runlevels:action:process<br />
</pre><br />
<br />
Dove {{Codeline|id}} è un identificatore univoco per la voce (solo un nome, non influisce su init), e {{Codeline|runlevels}} è una stringa (non delimitata) di runlevel. Se il runlevel in cui entra {{Codeline|init}} compare in {{Codeline|runlevels}}, allora {{Codeline|action}} verra svolta, eseguendo {{Codeline|process}}. Alcune {{Codeline|action}} speciali potrebbero portare {{Codeline|init}} ad ignorare {{Codeline|runlevels}} ed adottare un corrispondente metodo. Maggiori spiegazioni seguono nella sezione successiva.<br />
<br />
==Cambiare runlevel==<br />
Dopo che il sistema è stato avviato, è possibile invocare {{Codeline|telinit n}} per dire ad {{Codeline|init}} di cambiare il runlevel ad {{Codeline|'''n'''}}. {{Codeline|init}} quindi leggerà {{Filename|inittab}} e "confronterà" il runlevel {{Codeline|'''n'''}} con quello attuale - effettuando il kill dei processi non presenti nel nuovo runlevel e svolgendo le azioni non presenti nel vecchio runlevel. I processi presenti in entrambi i runlevel rimarranno invariati. La procedura di kill dei procsessi attualmente è un poco complessa; per maggiori informazioni e dettagli tecnici consultare la pagina di manuale di init.<br />
<br />
{{Codeline|init}} non riesaminerà {{Filename|inittab}}. Sarà necessario invocare {{Codeline|telinit}} esplicitamente per applicare le modifiche apportate ad {{Filename|inittab}}. Il comando {{Codeline|telinit q}} farà si che {{Codeline|init}} riesamini {{Filename|inittab}} ma non cambierà runlevel.<br />
<br />
==inittab==<br />
In questa sezione saranno esaminate le voci comuni di {{Filename|inittab}}, nel solito ordine in cui appaiono nel file di default usato da Arch. Successivamente verranno fatti alcuni esempi per aiutare a creare le proprie voci di {{Filename|inittab}}.<br />
<br />
{{Attenzione|Testare sempre il file {{Filename|/etc/inittab}} modificato usando il comando {{Codeline|telinit q}} prima di effettuare un riavvio, oppure eventuali errori di sintassi potrebbero impedire l'avvio del sistema.}}<br />
<br />
===Default Runlevel===<br />
Il runlevel di default è il numero 3. Decommentare o aggiungere questo se si preferisce avviare il sitema nel runlevel 5 (che è comunemente usato per avviare X) come default:<br />
<br />
<pre><br />
id:5:initdefault:<br />
</pre><br />
<br />
===Principali Script di Boot===<br />
Questi sono gli script di init principali di Arch.<br />
<br />
<pre><br />
rc::sysinit:/etc/rc.sysinit<br />
rs:S1:wait:/etc/rc.single<br />
rm:2345:wait:/etc/rc.multi<br />
rh:06:wait:/etc/rc.shutdown<br />
</pre><br />
<br />
===Avvio in Single User===<br />
A volte il kernel può fallire ad avviarsi, a causa di un file system corrotto o di un disco rotto, file chiave mancanti eccetera. In questo caso la propria immagine di init puà automaticamente entrare in '''single-user mode''' che permette di effettuare il login come root ed usa {{Filename|/sbin/sulogin}} invece di {{Filename|/sbin/login}} per controllare il processo di login. Si può entrare in single-user mode aggiungendo la lettera '''S''' alla linea di comando del kernel nella configurazione di [[GRUB (Italiano)|GRUB]], [[LILO (Italiano)|LILO]], o syslinux. Se si vuole eseguire qualcosa di diverso da {{Codeline|sulogin}}, specificarlo in questa voce.<br />
<pre><br />
su:S:wait:/sbin/sulogin -p<br />
</pre><br />
<br />
===Gettys e Login===<br />
Queste sono le voci fondamentali, esse eseguono le [[getty]] nei termninali. Molte configurazioni di default avranno le getty eseguite sulle {{Codeline|ttys1-6}} che effettueranno la visualizzazione della richiesta di login. Vedere anche {{Codeline|openvt, chvt, stty}} ed {{Codeline|ioctl}}<br />
<pre><br />
c1:234:respawn:/sbin/agetty 9600 tty1 xterm-color<br />
c5:5:respawn:/sbin/agetty 57600 tty2 xterm-256color<br />
</pre><br />
<br />
===Ctrl-Alt-Del===<br />
Quando viene premuta la sequenza di tasti speciali {{Keypress|CTRL}}+{{Keypress|ALT}}+{{Keypress|DEL}}, questa voce determina l'azione che verrà eseguita.<br />
<pre><br />
ca::ctrlaltdel:/sbin/shutdown -t3 -r now<br />
</pre><br />
<br />
===Programmi X===<br />
Se non si è interessati al debub, è possibile avviare ogni tipo di applicazione tramite {{Filename|inittab}}. Un programma utile da avviare è il login manager desiderato quando si entra nel runlevel 5, multi-user-x-mode. Nel seguente esempio si può vedere come avviare [[SLiM (Italiano)|slim]] entrando nel runlevel 5.<br />
<pre><br />
x:5:respawn:/usr/bin/slim >/dev/null 2>&1<br />
#x:5:respawn:/usr/bin/xdm -nodaemon -confi /etc/X11/xdm/archlinux/xdm-config<br />
</pre><br />
<br />
===Script Power-Sensing===<br />
{{Codeline|Init}} può comunicare con gli UPS (gruppi di continuità) ed eseguire processi in base allo stato del'UPS. Ecco alcuni esempi:<br />
<pre><br />
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"<br />
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"<br />
</pre><br />
<br />
===Combinazioni di tasti personalizzati===<br />
Le seguenti linee aggiungono funzioni personalizzate quando una sequenza di tasti speciali vengono premuti. Si possono modificare queste sequenze per effettuare ciò che si preferisce, seguendo la sintassi di [[#Ctrl-Alt-Del|ctrl-alt-del]]<br />
<pre><br />
kb::kbrequest:/usr/bin/wall "Keyboard Request -- edit /etc/inittab to customize"<br />
</pre><br />
<br />
====Sollevare una kbrequest====<br />
E' possibile simulare la sequenza speciale di tasti '''kbrequest''' inviando il segnale WINCH al processo di init(1) come root (tramite sudo). In questo esempio, il comando:<br />
kill -WINCH 1<br />
causa la scrittura da parte di wall su tutti i tty di:<br />
<pre><br />
Broadcast message from root@askapachehost (console) (Wed Oct 27 14:02:26 2010): <br />
Keyboard Request -- edit /etc/inittab to customize<br />
</pre><br />
<br />
==Vedere Anche==<br />
*[[Start X at boot (Italiano)]]<br />
*[[Automatic login to virtual console (Italiano)]]<br />
*[[Display Manager (Italiano)]]<br />
*[[Disable Clearing of Boot Messages]]<br />
*[[xinitrc (Italiano)]]<br />
*[[SLiM (Italiano)]]<br />
<br />
==Link Esterni==<br />
* [http://en.wikipedia.org/wiki/Init Wikipedia: Init]<br />
* [http://www.linux-tutorial.info/modules.php?name=MContent&pageid=65 Conoscenze di base di Linux e turorial. Runlevel.]<br />
* [http://www.linux.com/articles/114107 Linux.com. Introduzione ai runlevel ed inittab(inglese)]<br />
* [http://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts Linux.com. una introduction ai servizi, runlevel, ed agli script rc.d.]</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=SysVinit_(Italiano)&diff=161205SysVinit (Italiano)2011-09-21T14:46:11Z<p>Lorenzog: /* See Also */</p>
<hr />
<div>[[Category:Boot process (Italiano)]]<br />
[[Category:Daemons and system services (Italiano)]]<br />
[[Category:System administration (Italiano)]]<br />
[[Category:System recovery (Italiano)]]<br />
{{i18n|Init and inittab}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
'''init''' è il primo processo che viene eseguito una volta che il kernel Linux è stato caricato. Il programma di init di default usato da Arch è {{Filename|/sbin/init}} ed è fortniro dal pacchetto {{Package Official|sysvinit}}. La parola {{Codeline|'''init'''}} in questo articolo si riferirà a {{Codeline|sysvinit}}.<br />
<br />
'''inittab''' è il file di configurazione dell'avvio per {{Codeline|init}} e si trova in {{Filename|/etc}}. Esso contiene le cartelle per {{Codeline|init}} o quali programmi o script eseguire quando si entra in uno specifico runlervel.<br />
<br />
{{Tip|Consultare {{Codeline|man 5 inittab}} e {{Codeline|man 8 init}} per una descrizione più completa e formale.}}<br />
<br />
{{Tip|Sebbene Arch utilizzi {{Codeline|init}}, la maggiorparte del lavoro viene delegato ai [[#Principali Script di Boot|principali script di boot]]. Questo articolo traterà principalmente {{Codeline|init}} ed {{Filename|inittab}}; per maggiori informazioni sul processo di avvio di Arch consultare [[Arch Boot Process (Italiano)|Arch Boot Process]].}}<br />
<br />
==Parametri del kernel correlati==<br />
<br />
Per utilizzare un altro programma di {{Codeline|init}} (es. [[systemd (Italiano)|systemd]]), aggiungere {{Codeline|'''init<nowiki>=</nowiki>/bin/systemd'''}} o simile alla riga del kernel in [[GRUB (Italiano)|GRUB]]. Per cambiare il runlevel in cui il sistema effettua il boot, semplicemente aggiungere il runlevel desiderato {{Codeline|'''n'''}} alla riga del kernel. Un comune uso di questo può essere trovato in [[Start_X_at_boot (Italiano)#/etc/inittab|qeusto articolo]].<br />
{{Nota|Se si utilizza un programma di init diverso da {{Codeline|sysvinit}}, il parametro del runlevel potrebbe essere ignorato.}}<br />
<br />
==Panoramica di init e inittab==<br />
<br />
{{Codeline|init}} è sempre il processso con PID 1 ed all'infuori della gestione dell'area di swap, è il processo genitore per '''tutti''' gli altri processi. Può essere notato meglio il ruolo che svolge init nella gerarchia dei processi del proprio sistema usando il comando {{Codeline|pstree}}:<br />
<br />
{{Command|pstree -Ap|<nowiki><br />
init(1)-+-acpid(3432)<br />
|-crond(3423)<br />
|-dbus-daemon(3469)<br />
|-gpm(3485)<br />
|-mylogin(3536)<br />
|-ngetty(3535)---login(3954)---zsh(4043)---pstree(4326)<br />
|-polkitd(4033)---{polkitd}(4035)<br />
|-syslog-ng(3413)---syslog-ng(3414)<br />
`-udevd(643)-+-udevd(3194)<br />
`-udevd(3218)<br />
</nowiki>}}<br />
<br />
Oltre alle comuni inizializzazioni di sistema (come suggerisce il nome), {{Codeline|init}} si occupa del riavvio, dello spengimento e del avvio in recovery mode (single-user-mode). Per supportare tutto questo il file {{Filename|inittab}} raggruppa queste modalità in diversi '''runlevel'''. I runlevel usati da Arch sono 0 per lo spengimento, 1 (oppure S che è un suo alias) per il single-user-mode, 3 per il normale boot (multi-user-mode), 5 per [[Xorg (Italiano)|X]] e 6 per il riavvio. Altre distribuzioni possono adottare altre convenzioni, ma l'uso dei runlevel 0, 1 e 6 è universale.<br />
<br />
<br />
Al momento dell'esecuzione, {{Codeline|init}} scansiona {{Filename|inittab}} ed effettua le appropriate azioni. Una voce di {{Filename|inittab}} ha questa forma:<br />
<br />
<pre><br />
id:runlevels:action:process<br />
</pre><br />
<br />
Dove {{Codeline|id}} è un identificatore univoco per la voce (solo un nome, non influisce su init), e {{Codeline|runlevels}} è una stringa (non delimitata) di runlevel. Se il runlevel in cui entra {{Codeline|init}} compare in {{Codeline|runlevels}}, allora {{Codeline|action}} verra svolta, eseguendo {{Codeline|process}}. Alcune {{Codeline|action}} speciali potrebbero portare {{Codeline|init}} ad ignorare {{Codeline|runlevels}} ed adottare un corrispondente metodo. Maggiori spiegazioni seguono nella sezione successiva.<br />
<br />
==Cambiare runlevel==<br />
Dopo che il sistema è stato avviato, è possibile invocare {{Codeline|telinit n}} per dire ad {{Codeline|init}} di cambiare il runlevel ad {{Codeline|'''n'''}}. {{Codeline|init}} quindi leggerà {{Filename|inittab}} e "confronterà" il runlevel {{Codeline|'''n'''}} con quello attuale - effettuando il kill dei processi non presenti nel nuovo runlevel e svolgendo le azioni non presenti nel vecchio runlevel. I processi presenti in entrambi i runlevel rimarranno invariati. La procedura di kill dei procsessi attualmente è un poco complessa; per maggiori informazioni e dettagli tecnici consultare la pagina di manuale di init.<br />
<br />
{{Codeline|init}} non riesaminerà {{Filename|inittab}}. Sarà necessario invocare {{Codeline|telinit}} esplicitamente per applicare le modifiche apportate ad {{Filename|inittab}}. Il comando {{Codeline|telinit q}} farà si che {{Codeline|init}} riesamini {{Filename|inittab}} ma non cambierà runlevel.<br />
<br />
==inittab==<br />
In questa sezione saranno esaminate le voci comuni di {{Filename|inittab}}, nel solito ordine in cui appaiono nel file di default usato da Arch. Successivamente verranno fatti alcuni esempi per aiutare a creare le proprie voci di {{Filename|inittab}}.<br />
<br />
{{Attenzione|Testare sempre il file {{Filename|/etc/inittab}} modificato usando il comando {{Codeline|telinit q}} prima di effettuare un riavvio, oppure eventuali errori di sintassi potrebbero impedire l'avvio del sistema.}}<br />
<br />
===Default Runlevel===<br />
Il runlevel di default è il numero 3. Decommentare o aggiungere questo se si preferisce avviare il sitema nel runlevel 5 (che è comunemente usato per avviare X) come default:<br />
<br />
<pre><br />
id:5:initdefault:<br />
</pre><br />
<br />
===Principali Script di Boot===<br />
Questi sono gli script di init principali di Arch.<br />
<br />
<pre><br />
rc::sysinit:/etc/rc.sysinit<br />
rs:S1:wait:/etc/rc.single<br />
rm:2345:wait:/etc/rc.multi<br />
rh:06:wait:/etc/rc.shutdown<br />
</pre><br />
<br />
===Avvio in Single User===<br />
A volte il kernel può fallire ad avviarsi, a causa di un file system corrotto o di un disco rotto, file chiave mancanti eccetera. In questo caso la propria immagine di init puà automaticamente entrare in '''single-user mode''' che permette di effettuare il login come root ed usa {{Filename|/sbin/sulogin}} invece di {{Filename|/sbin/login}} per controllare il processo di login. Si può entrare in single-user mode aggiungendo la lettera '''S''' alla linea di comando del kernel nella configurazione di [[GRUB (Italiano)|GRUB]], [[LILO (Italiano)|LILO]], o syslinux. Se si vuole eseguire qualcosa di diverso da {{Codeline|sulogin}}, specificarlo in questa voce.<br />
<pre><br />
su:S:wait:/sbin/sulogin -p<br />
</pre><br />
<br />
===Gettys e Login===<br />
Queste sono le voci fondamentali, esse eseguono le [[getty]] nei termninali. Molte configurazioni di default avranno le getty eseguite sulle {{Codeline|ttys1-6}} che effettueranno la visualizzazione della richiesta di login. Vedere anche {{Codeline|openvt, chvt, stty}} ed {{Codeline|ioctl}}<br />
<pre><br />
c1:234:respawn:/sbin/agetty 9600 tty1 xterm-color<br />
c5:5:respawn:/sbin/agetty 57600 tty2 xterm-256color<br />
</pre><br />
<br />
===Ctrl-Alt-Del===<br />
Quando viene premuta la sequenza di tasti speciali {{Keypress|CTRL}}+{{Keypress|ALT}}+{{Keypress|DEL}}, questa voce determina l'azione che verrà eseguita.<br />
<pre><br />
ca::ctrlaltdel:/sbin/shutdown -t3 -r now<br />
</pre><br />
<br />
===Programmi X===<br />
Se non si è interessati al debub, è possibile avviare ogni tipo di applicazione tramite {{Filename|inittab}}. Un programma utile da avviare è il login manager desiderato quando si entra nel runlevel 5, multi-user-x-mode. Nel seguente esempio si può vedere come avviare [[SLiM (Italiano)|slim]] entrando nel runlevel 5.<br />
<pre><br />
x:5:respawn:/usr/bin/slim >/dev/null 2>&1<br />
#x:5:respawn:/usr/bin/xdm -nodaemon -confi /etc/X11/xdm/archlinux/xdm-config<br />
</pre><br />
<br />
===Script Power-Sensing===<br />
{{Codeline|Init}} può comunicare con gli UPS (gruppi di continuità) ed eseguire processi in base allo stato del'UPS. Ecco alcuni esempi:<br />
<pre><br />
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"<br />
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"<br />
</pre><br />
<br />
===Combinazioni di tasti personalizzati===<br />
Le seguenti linee aggiungono funzioni personalizzate quando una sequenza di tasti speciali vengono premuti. Si possono modificare queste sequenze per effettuare ciò che si preferisce, seguendo la sintassi di [[#Ctrl-Alt-Del|ctrl-alt-del]]<br />
<pre><br />
kb::kbrequest:/usr/bin/wall "Keyboard Request -- edit /etc/inittab to customize"<br />
</pre><br />
<br />
====Sollevare una kbrequest====<br />
E' possibile simulare la sequenza speciale di tasti '''kbrequest''' inviando il segnale WINCH al processo di init(1) come root (tramite sudo). In questo esempio, il comando:<br />
kill -WINCH 1<br />
causa la scrittura da parte di wall su tutti i tty di:<br />
<pre><br />
Broadcast message from root@askapachehost (console) (Wed Oct 27 14:02:26 2010): <br />
Keyboard Request -- edit /etc/inittab to customize<br />
</pre><br />
<br />
==Vedere Anche==<br />
*[[Start X at boot (Italiano)]]<br />
*[[Automatic login to virtual console (Italiano)]]<br />
*[[Display Manager (Italiano)]]<br />
*[[Disable Clearing of Boot Messages]]<br />
*[[xinitrc (Italiano)]]<br />
*[[SLiM (Italiano)]]<br />
<br />
==Link Esterni==<br />
* [http://en.wikipedia.org/wiki/Init Wikipedia: Init]<br />
* [http://www.linux-tutorial.info/modules.php?name=MContent&pageid=65 Conoscenze di base di Linux e turorial. Runlevel.]<br />
* [http://www.linux.com/articles/114107 Linux.com. Introduzione ai runlevel ed inittab(inglese)]<br />
* [http://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts Linux.com. una introduction ai servizi, runlevel, ed agli script rc.d.]</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=SysVinit_(Italiano)&diff=161202SysVinit (Italiano)2011-09-21T14:42:26Z<p>Lorenzog: /* Trigger the kbrequest */</p>
<hr />
<div>[[Category:Boot process (Italiano)]]<br />
[[Category:Daemons and system services (Italiano)]]<br />
[[Category:System administration (Italiano)]]<br />
[[Category:System recovery (Italiano)]]<br />
{{i18n|Init and inittab}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
'''init''' è il primo processo che viene eseguito una volta che il kernel Linux è stato caricato. Il programma di init di default usato da Arch è {{Filename|/sbin/init}} ed è fortniro dal pacchetto {{Package Official|sysvinit}}. La parola {{Codeline|'''init'''}} in questo articolo si riferirà a {{Codeline|sysvinit}}.<br />
<br />
'''inittab''' è il file di configurazione dell'avvio per {{Codeline|init}} e si trova in {{Filename|/etc}}. Esso contiene le cartelle per {{Codeline|init}} o quali programmi o script eseguire quando si entra in uno specifico runlervel.<br />
<br />
{{Tip|Consultare {{Codeline|man 5 inittab}} e {{Codeline|man 8 init}} per una descrizione più completa e formale.}}<br />
<br />
{{Tip|Sebbene Arch utilizzi {{Codeline|init}}, la maggiorparte del lavoro viene delegato ai [[#Principali Script di Boot|principali script di boot]]. Questo articolo traterà principalmente {{Codeline|init}} ed {{Filename|inittab}}; per maggiori informazioni sul processo di avvio di Arch consultare [[Arch Boot Process (Italiano)|Arch Boot Process]].}}<br />
<br />
==Parametri del kernel correlati==<br />
<br />
Per utilizzare un altro programma di {{Codeline|init}} (es. [[systemd (Italiano)|systemd]]), aggiungere {{Codeline|'''init<nowiki>=</nowiki>/bin/systemd'''}} o simile alla riga del kernel in [[GRUB (Italiano)|GRUB]]. Per cambiare il runlevel in cui il sistema effettua il boot, semplicemente aggiungere il runlevel desiderato {{Codeline|'''n'''}} alla riga del kernel. Un comune uso di questo può essere trovato in [[Start_X_at_boot (Italiano)#/etc/inittab|qeusto articolo]].<br />
{{Nota|Se si utilizza un programma di init diverso da {{Codeline|sysvinit}}, il parametro del runlevel potrebbe essere ignorato.}}<br />
<br />
==Panoramica di init e inittab==<br />
<br />
{{Codeline|init}} è sempre il processso con PID 1 ed all'infuori della gestione dell'area di swap, è il processo genitore per '''tutti''' gli altri processi. Può essere notato meglio il ruolo che svolge init nella gerarchia dei processi del proprio sistema usando il comando {{Codeline|pstree}}:<br />
<br />
{{Command|pstree -Ap|<nowiki><br />
init(1)-+-acpid(3432)<br />
|-crond(3423)<br />
|-dbus-daemon(3469)<br />
|-gpm(3485)<br />
|-mylogin(3536)<br />
|-ngetty(3535)---login(3954)---zsh(4043)---pstree(4326)<br />
|-polkitd(4033)---{polkitd}(4035)<br />
|-syslog-ng(3413)---syslog-ng(3414)<br />
`-udevd(643)-+-udevd(3194)<br />
`-udevd(3218)<br />
</nowiki>}}<br />
<br />
Oltre alle comuni inizializzazioni di sistema (come suggerisce il nome), {{Codeline|init}} si occupa del riavvio, dello spengimento e del avvio in recovery mode (single-user-mode). Per supportare tutto questo il file {{Filename|inittab}} raggruppa queste modalità in diversi '''runlevel'''. I runlevel usati da Arch sono 0 per lo spengimento, 1 (oppure S che è un suo alias) per il single-user-mode, 3 per il normale boot (multi-user-mode), 5 per [[Xorg (Italiano)|X]] e 6 per il riavvio. Altre distribuzioni possono adottare altre convenzioni, ma l'uso dei runlevel 0, 1 e 6 è universale.<br />
<br />
<br />
Al momento dell'esecuzione, {{Codeline|init}} scansiona {{Filename|inittab}} ed effettua le appropriate azioni. Una voce di {{Filename|inittab}} ha questa forma:<br />
<br />
<pre><br />
id:runlevels:action:process<br />
</pre><br />
<br />
Dove {{Codeline|id}} è un identificatore univoco per la voce (solo un nome, non influisce su init), e {{Codeline|runlevels}} è una stringa (non delimitata) di runlevel. Se il runlevel in cui entra {{Codeline|init}} compare in {{Codeline|runlevels}}, allora {{Codeline|action}} verra svolta, eseguendo {{Codeline|process}}. Alcune {{Codeline|action}} speciali potrebbero portare {{Codeline|init}} ad ignorare {{Codeline|runlevels}} ed adottare un corrispondente metodo. Maggiori spiegazioni seguono nella sezione successiva.<br />
<br />
==Cambiare runlevel==<br />
Dopo che il sistema è stato avviato, è possibile invocare {{Codeline|telinit n}} per dire ad {{Codeline|init}} di cambiare il runlevel ad {{Codeline|'''n'''}}. {{Codeline|init}} quindi leggerà {{Filename|inittab}} e "confronterà" il runlevel {{Codeline|'''n'''}} con quello attuale - effettuando il kill dei processi non presenti nel nuovo runlevel e svolgendo le azioni non presenti nel vecchio runlevel. I processi presenti in entrambi i runlevel rimarranno invariati. La procedura di kill dei procsessi attualmente è un poco complessa; per maggiori informazioni e dettagli tecnici consultare la pagina di manuale di init.<br />
<br />
{{Codeline|init}} non riesaminerà {{Filename|inittab}}. Sarà necessario invocare {{Codeline|telinit}} esplicitamente per applicare le modifiche apportate ad {{Filename|inittab}}. Il comando {{Codeline|telinit q}} farà si che {{Codeline|init}} riesamini {{Filename|inittab}} ma non cambierà runlevel.<br />
<br />
==inittab==<br />
In questa sezione saranno esaminate le voci comuni di {{Filename|inittab}}, nel solito ordine in cui appaiono nel file di default usato da Arch. Successivamente verranno fatti alcuni esempi per aiutare a creare le proprie voci di {{Filename|inittab}}.<br />
<br />
{{Attenzione|Testare sempre il file {{Filename|/etc/inittab}} modificato usando il comando {{Codeline|telinit q}} prima di effettuare un riavvio, oppure eventuali errori di sintassi potrebbero impedire l'avvio del sistema.}}<br />
<br />
===Default Runlevel===<br />
Il runlevel di default è il numero 3. Decommentare o aggiungere questo se si preferisce avviare il sitema nel runlevel 5 (che è comunemente usato per avviare X) come default:<br />
<br />
<pre><br />
id:5:initdefault:<br />
</pre><br />
<br />
===Principali Script di Boot===<br />
Questi sono gli script di init principali di Arch.<br />
<br />
<pre><br />
rc::sysinit:/etc/rc.sysinit<br />
rs:S1:wait:/etc/rc.single<br />
rm:2345:wait:/etc/rc.multi<br />
rh:06:wait:/etc/rc.shutdown<br />
</pre><br />
<br />
===Avvio in Single User===<br />
A volte il kernel può fallire ad avviarsi, a causa di un file system corrotto o di un disco rotto, file chiave mancanti eccetera. In questo caso la propria immagine di init puà automaticamente entrare in '''single-user mode''' che permette di effettuare il login come root ed usa {{Filename|/sbin/sulogin}} invece di {{Filename|/sbin/login}} per controllare il processo di login. Si può entrare in single-user mode aggiungendo la lettera '''S''' alla linea di comando del kernel nella configurazione di [[GRUB (Italiano)|GRUB]], [[LILO (Italiano)|LILO]], o syslinux. Se si vuole eseguire qualcosa di diverso da {{Codeline|sulogin}}, specificarlo in questa voce.<br />
<pre><br />
su:S:wait:/sbin/sulogin -p<br />
</pre><br />
<br />
===Gettys e Login===<br />
Queste sono le voci fondamentali, esse eseguono le [[getty]] nei termninali. Molte configurazioni di default avranno le getty eseguite sulle {{Codeline|ttys1-6}} che effettueranno la visualizzazione della richiesta di login. Vedere anche {{Codeline|openvt, chvt, stty}} ed {{Codeline|ioctl}}<br />
<pre><br />
c1:234:respawn:/sbin/agetty 9600 tty1 xterm-color<br />
c5:5:respawn:/sbin/agetty 57600 tty2 xterm-256color<br />
</pre><br />
<br />
===Ctrl-Alt-Del===<br />
Quando viene premuta la sequenza di tasti speciali {{Keypress|CTRL}}+{{Keypress|ALT}}+{{Keypress|DEL}}, questa voce determina l'azione che verrà eseguita.<br />
<pre><br />
ca::ctrlaltdel:/sbin/shutdown -t3 -r now<br />
</pre><br />
<br />
===Programmi X===<br />
Se non si è interessati al debub, è possibile avviare ogni tipo di applicazione tramite {{Filename|inittab}}. Un programma utile da avviare è il login manager desiderato quando si entra nel runlevel 5, multi-user-x-mode. Nel seguente esempio si può vedere come avviare [[SLiM (Italiano)|slim]] entrando nel runlevel 5.<br />
<pre><br />
x:5:respawn:/usr/bin/slim >/dev/null 2>&1<br />
#x:5:respawn:/usr/bin/xdm -nodaemon -confi /etc/X11/xdm/archlinux/xdm-config<br />
</pre><br />
<br />
===Script Power-Sensing===<br />
{{Codeline|Init}} può comunicare con gli UPS (gruppi di continuità) ed eseguire processi in base allo stato del'UPS. Ecco alcuni esempi:<br />
<pre><br />
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"<br />
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"<br />
</pre><br />
<br />
===Combinazioni di tasti personalizzati===<br />
Le seguenti linee aggiungono funzioni personalizzate quando una sequenza di tasti speciali vengono premuti. Si possono modificare queste sequenze per effettuare ciò che si preferisce, seguendo la sintassi di [[#Ctrl-Alt-Del|ctrl-alt-del]]<br />
<pre><br />
kb::kbrequest:/usr/bin/wall "Keyboard Request -- edit /etc/inittab to customize"<br />
</pre><br />
<br />
====Sollevare una kbrequest====<br />
E' possibile simulare la sequenza speciale di tasti '''kbrequest''' inviando il segnale WINCH al processo di init(1) come root (tramite sudo). In questo esempio, il comando:<br />
kill -WINCH 1<br />
causa la scrittura da parte di wall su tutti i tty di:<br />
<pre><br />
Broadcast message from root@askapachehost (console) (Wed Oct 27 14:02:26 2010): <br />
Keyboard Request -- edit /etc/inittab to customize<br />
</pre><br />
<br />
==See Also==<br />
*[[Start X at boot]]<br />
*[[Automatically login some user to a virtual console on startup]]<br />
*[[Display Manager]]<br />
*[[Disable Clearing of Boot Messages]]<br />
*[[xinitrc]]<br />
*[[slim]]<br />
<br />
==Link Esterni==<br />
* [http://en.wikipedia.org/wiki/Init Wikipedia: Init]<br />
* [http://www.linux-tutorial.info/modules.php?name=MContent&pageid=65 Conoscenze di base di Linux e turorial. Runlevel.]<br />
* [http://www.linux.com/articles/114107 Linux.com. Introduzione ai runlevel ed inittab(inglese)]<br />
* [http://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts Linux.com. una introduction ai servizi, runlevel, ed agli script rc.d.]</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156198Solid state drive (Italiano)2011-09-05T22:09:26Z<p>Lorenzog: tolto tag translateme</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
== Consigli per Minimizzare Letture/Scritture su SSD ==<br />
Uno schema di utilizzo per gli SSD dovrebbe basarsi sulla 'semplicità' di posizionare le operazioni che richiedono numerose letture e scritture in RAM (Random Access Memory) o su un HDD fisico piuttosto che sul SSD. Così facendo si aumenta la longevità del SSD. Questo è principalmente dovuto ad un erase block size grande (512 KiB in alcuni casi); molte piccole scritture causano un numero gigante di effettive scritture. <br />
<br />
{{Note|Un SSD da 32GB con un fattore di amplificazione di scrittura di 10x, un ciclo standard di 10000 scritture/cancellazioni, e '''10GB di dati scritti al giorno''', darebbero '''un aspettativa di vita di 8 anni'''. La situazione migliora con SSD più grandi e controller moderni con fattori di amplificazione di scrittura minori.}}<br />
<br />
Usare "iotop -oPa" e ordinare in base alle scritture su disco per vedere quanto i programmi stanno scrivendo su disco.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Posizionare /tmp in RAM ===<br />
Per sistemi con almeno 2 giga di memoria, posizionare /tmp in RAM è consigliato e anche facilmente realizzabile cancellando il contenuto della partizione fisica per /tmp e successivamente montarla su tmpfs (RAM) in {{Filename|/etc/fstab}}.<br />
La seguente linea ne è un esempio:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Posizonare i Profili del Browser in RAM ===<br />
E' possibile facilmente montare i profili dei browser come firefox, chromium, ecc. in RAM attraverso tmpfs e usare rsync per tenerli sincronizzati con i backup presenti su HDD. Per maggiori informazioni su questa procedura, vedere l'articolo [[Speed-up_Firefox_using_tmpfs|Velocizzare Firefox Usando tmpfs]]. Oltre all'ovvio incremento di velocità, in questo modo, sarà anche possibile prevenire cicli di lettura e scrittura sul proprio SSD.<br />
<br />
=== Compilare in /dev/shm ===<br />
Compilare intenzionalmente in /dev/shm è un'ottima idea per minimizzare questo problema. Per sistemi con almeno 4 Giga di memoria, la linea relativa a shm presente in {{Filename|/etc/fstab}} può essere modificata in modo da usare più della metà della memoria fisica disponibile grazie all'utilizzo dell'opzione size.<br />
<br />
Esempio di una macchina con 8 GiB di memoria fisica:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabilitare il Journaling sul Filesystem? ===<br />
L'utilizzo di un filesystem con journaling come ext3 o ext4 su un SSD SENZA il journal è un opzione per diminuire letture/scritture. L'ovvia controindicazione dell'utilizzo di un filesystem con il journaling disabilitato è una perdita di dati in caso di un dismount problematico (ad esempio un'interruzione di alimentazione, blocco del kernel, ecc.). Con i moderni SSD [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] argomenta che il journaling può essere abilitato con il minimo di numero di letture/scritture supplementare nella maggior parte delle circostanze: <br />
<br />
'''Quantità di dati scritti (in megabyte) su un file system ext4 montato con l'opzione noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operazione !! con journal !! senza journal !! differenza percentuale<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"Quello che i risultati dimostrano è che carichi di lavoro pesanti per i metadati, come un make clean, raddoppiano la quantità di dati scritti sul disco. Questo è naturale, dal momento che tutt i cambiamenti ai blocchi dei metadati sono prima scritti sul journal e la transazione del journal viene completata prima che i metadati vengano scritti nella loro posizione finale sul disco. Comunque per carichi di lavoro più comuni dove avvengono scritture e modifiche di blocchi metadati, la differenza è molto più piccola."''<br />
<br />
{{Note|L'esempio di make clean della tabella precedente enfatizza l'importanza di compilare intenzionalmente in /dev/shm come raccomandato nella [[#Compilare_in_.2Fdev.2Fshm|precedente sezione]] di questo articolo!}}<br />
<br />
=== Scelta del Filesystem ===<br />
Esistono molte opzioni per i filesystem inclusi ext2, ext3, ext4, btrfs, ecc.<br />
<br />
==== Btrfs ====<br />
Il supporto a [http://it.wikipedia.org/wiki/Btrfs Btrfs] è stato incluso con la release principale del kernel Linux versione 2.6.29. Qualcuno sostiene che non sia abbastanza maturo per l'utilizzo in ambienti di produzione mentre altri già da tempo utilizzano questo potenziale successore di ext4. Notare che quando questo articolo è stato originariamente scritto (27-Giugno-2010), una versione stabile di btfrs non esiste. Vedere [http://www.madeo.co.uk/?p=346 questo] articolo di blog per maggiori informazioni su btfrs. Assicurarsi di leggere anche il [https://btrfs.wiki.kernel.org/index.php/Main_Page wiki di btfrs].<br />
<br />
{{Warning|Al momento in cui questo è stato scritto (21-Nov-2010) non esiste un utility fsck per diagnosticare e correggere errori sulle partizioni btrfs. Mentre Btrfs è stabile su una macchina stabile, è attualmente possibile corrompere irrimediabilmente un filesystem nel caso di crash o interruzione di alimentazione ai dischi che non gestiscono le richieste di flush correttamente.}}<br />
<br />
==== Ext4 ====<br />
[http://it.wikipedia.org/wiki/Ext4 Ext4] è un altro filsesystem che supporta gli SSD. Viene considerato stabile a partire dalla versione 2.6.28 ed è sufficientemente maturo per un uso quotidiano. Contrariamente a btrfs, ext4 non riconosce automaticamente la natura del disco ed è necessario abilitare esplicitamente il supporto al comando TRIM attraverso l'opzione di mount '''discard''' in [[fstab]] (oppure con tune2fs -o discard /dev/sdaX).<br />
Vedere la [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD documentazione ufficiale del kernel] per maggiori informazioni su ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156193Solid state drive (Italiano)2011-09-05T22:08:35Z<p>Lorenzog: /* Tips for Minimizing SSD Read/Writes */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
== Consigli per Minimizzare Letture/Scritture su SSD ==<br />
Uno schema di utilizzo per gli SSD dovrebbe basarsi sulla 'semplicità' di posizionare le operazioni che richiedono numerose letture e scritture in RAM (Random Access Memory) o su un HDD fisico piuttosto che sul SSD. Così facendo si aumenta la longevità del SSD. Questo è principalmente dovuto ad un erase block size grande (512 KiB in alcuni casi); molte piccole scritture causano un numero gigante di effettive scritture. <br />
<br />
{{Note|Un SSD da 32GB con un fattore di amplificazione di scrittura di 10x, un ciclo standard di 10000 scritture/cancellazioni, e '''10GB di dati scritti al giorno''', darebbero '''un aspettativa di vita di 8 anni'''. La situazione migliora con SSD più grandi e controller moderni con fattori di amplificazione di scrittura minori.}}<br />
<br />
Usare "iotop -oPa" e ordinare in base alle scritture su disco per vedere quanto i programmi stanno scrivendo su disco.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Posizionare /tmp in RAM ===<br />
Per sistemi con almeno 2 giga di memoria, posizionare /tmp in RAM è consigliato e anche facilmente realizzabile cancellando il contenuto della partizione fisica per /tmp e successivamente montarla su tmpfs (RAM) in {{Filename|/etc/fstab}}.<br />
La seguente linea ne è un esempio:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Posizonare i Profili del Browser in RAM ===<br />
E' possibile facilmente montare i profili dei browser come firefox, chromium, ecc. in RAM attraverso tmpfs e usare rsync per tenerli sincronizzati con i backup presenti su HDD. Per maggiori informazioni su questa procedura, vedere l'articolo [[Speed-up_Firefox_using_tmpfs|Velocizzare Firefox Usando tmpfs]]. Oltre all'ovvio incremento di velocità, in questo modo, sarà anche possibile prevenire cicli di lettura e scrittura sul proprio SSD.<br />
<br />
=== Compilare in /dev/shm ===<br />
Compilare intenzionalmente in /dev/shm è un'ottima idea per minimizzare questo problema. Per sistemi con almeno 4 Giga di memoria, la linea relativa a shm presente in {{Filename|/etc/fstab}} può essere modificata in modo da usare più della metà della memoria fisica disponibile grazie all'utilizzo dell'opzione size.<br />
<br />
Esempio di una macchina con 8 GiB di memoria fisica:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabilitare il Journaling sul Filesystem? ===<br />
L'utilizzo di un filesystem con journaling come ext3 o ext4 su un SSD SENZA il journal è un opzione per diminuire letture/scritture. L'ovvia controindicazione dell'utilizzo di un filesystem con il journaling disabilitato è una perdita di dati in caso di un dismount problematico (ad esempio un'interruzione di alimentazione, blocco del kernel, ecc.). Con i moderni SSD [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] argomenta che il journaling può essere abilitato con il minimo di numero di letture/scritture supplementare nella maggior parte delle circostanze: <br />
<br />
'''Quantità di dati scritti (in megabyte) su un file system ext4 montato con l'opzione noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operazione !! con journal !! senza journal !! differenza percentuale<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"Quello che i risultati dimostrano è che carichi di lavoro pesanti per i metadati, come un make clean, raddoppiano la quantità di dati scritti sul disco. Questo è naturale, dal momento che tutt i cambiamenti ai blocchi dei metadati sono prima scritti sul journal e la transazione del journal viene completata prima che i metadati vengano scritti nella loro posizione finale sul disco. Comunque per carichi di lavoro più comuni dove avvengono scritture e modifiche di blocchi metadati, la differenza è molto più piccola."''<br />
<br />
{{Note|L'esempio di make clean della tabella precedente enfatizza l'importanza di compilare intenzionalmente in /dev/shm come raccomandato nella [[#Compilare_in_.2Fdev.2Fshm|precedente sezione]] di questo articolo!}}<br />
<br />
=== Scelta del Filesystem ===<br />
Esistono molte opzioni per i filesystem inclusi ext2, ext3, ext4, btrfs, ecc.<br />
<br />
==== Btrfs ====<br />
Il supporto a [http://it.wikipedia.org/wiki/Btrfs Btrfs] è stato incluso con la release principale del kernel Linux versione 2.6.29. Qualcuno sostiene che non sia abbastanza maturo per l'utilizzo in ambienti di produzione mentre altri già da tempo utilizzano questo potenziale successore di ext4. Notare che quando questo articolo è stato originariamente scritto (27-Giugno-2010), una versione stabile di btfrs non esiste. Vedere [http://www.madeo.co.uk/?p=346 questo] articolo di blog per maggiori informazioni su btfrs. Assicurarsi di leggere anche il [https://btrfs.wiki.kernel.org/index.php/Main_Page wiki di btfrs].<br />
<br />
{{Warning|Al momento in cui questo è stato scritto (21-Nov-2010) non esiste un utility fsck per diagnosticare e correggere errori sulle partizioni btrfs. Mentre Btrfs è stabile su una macchina stabile, è attualmente possibile corrompere irrimediabilmente un filesystem nel caso di crash o interruzione di alimentazione ai dischi che non gestiscono le richieste di flush correttamente.}}<br />
<br />
==== Ext4 ====<br />
[http://it.wikipedia.org/wiki/Ext4 Ext4] è un altro filsesystem che supporta gli SSD. Viene considerato stabile a partire dalla versione 2.6.28 ed è sufficientemente maturo per un uso quotidiano. Contrariamente a btrfs, ext4 non riconosce automaticamente la natura del disco ed è necessario abilitare esplicitamente il supporto al comando TRIM attraverso l'opzione di mount '''discard''' in [[fstab]] (oppure con tune2fs -o discard /dev/sdaX).<br />
Vedere la [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD documentazione ufficiale del kernel] per maggiori informazioni su ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156185Solid state drive (Italiano)2011-09-05T22:00:24Z<p>Lorenzog: /* Disabling Journaling on the Filesystem? */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Posizionare /tmp in RAM ===<br />
Per sistemi con almeno 2 giga di memoria, posizionare /tmp in RAM è consigliato e anche facilmente realizzabile cancellando il contenuto della partizione fisica per /tmp e successivamente montarla su tmpfs (RAM) in {{Filename|/etc/fstab}}.<br />
La seguente linea ne è un esempio:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Posizonare i Profili del Browser in RAM ===<br />
E' possibile facilmente montare i profili dei browser come firefox, chromium, ecc. in RAM attraverso tmpfs e usare rsync per tenerli sincronizzati con i backup presenti su HDD. Per maggiori informazioni su questa procedura, vedere l'articolo [[Speed-up_Firefox_using_tmpfs|Velocizzare Firefox Usando tmpfs]]. Oltre all'ovvio incremento di velocità, in questo modo, sarà anche possibile prevenire cicli di lettura e scrittura sul proprio SSD.<br />
<br />
=== Compilare in /dev/shm ===<br />
Compilare intenzionalmente in /dev/shm è un'ottima idea per minimizzare questo problema. Per sistemi con almeno 4 Giga di memoria, la linea relativa a shm presente in {{Filename|/etc/fstab}} può essere modificata in modo da usare più della metà della memoria fisica disponibile grazie all'utilizzo dell'opzione size.<br />
<br />
Esempio di una macchina con 8 GiB di memoria fisica:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabilitare il Journaling sul Filesystem? ===<br />
L'utilizzo di un filesystem con journaling come ext3 o ext4 su un SSD SENZA il journal è un opzione per diminuire letture/scritture. L'ovvia controindicazione dell'utilizzo di un filesystem con il journaling disabilitato è una perdita di dati in caso di un dismount problematico (ad esempio un'interruzione di alimentazione, blocco del kernel, ecc.). Con i moderni SSD [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] argomenta che il journaling può essere abilitato con il minimo di numero di letture/scritture supplementare nella maggior parte delle circostanze: <br />
<br />
'''Quantità di dati scritti (in megabyte) su un file system ext4 montato con l'opzione noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operazione !! con journal !! senza journal !! differenza percentuale<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"Quello che i risultati dimostrano è che carichi di lavoro pesanti per i metadati, come un make clean, raddoppiano la quantità di dati scritti sul disco. Questo è naturale, dal momento che tutt i cambiamenti ai blocchi dei metadati sono prima scritti sul journal e la transazione del journal viene completata prima che i metadati vengano scritti nella loro posizione finale sul disco. Comunque per carichi di lavoro più comuni dove avvengono scritture e modifiche di blocchi metadati, la differenza è molto più piccola."''<br />
<br />
{{Note|L'esempio di make clean della tabella precedente enfatizza l'importanza di compilare intenzionalmente in /dev/shm come raccomandato nella [[#Compilare_in_.2Fdev.2Fshm|precedente sezione]] di questo articolo!}}<br />
<br />
=== Scelta del Filesystem ===<br />
Esistono molte opzioni per i filesystem inclusi ext2, ext3, ext4, btrfs, ecc.<br />
<br />
==== Btrfs ====<br />
Il supporto a [http://it.wikipedia.org/wiki/Btrfs Btrfs] è stato incluso con la release principale del kernel Linux versione 2.6.29. Qualcuno sostiene che non sia abbastanza maturo per l'utilizzo in ambienti di produzione mentre altri già da tempo utilizzano questo potenziale successore di ext4. Notare che quando questo articolo è stato originariamente scritto (27-Giugno-2010), una versione stabile di btfrs non esiste. Vedere [http://www.madeo.co.uk/?p=346 questo] articolo di blog per maggiori informazioni su btfrs. Assicurarsi di leggere anche il [https://btrfs.wiki.kernel.org/index.php/Main_Page wiki di btfrs].<br />
<br />
{{Warning|Al momento in cui questo è stato scritto (21-Nov-2010) non esiste un utility fsck per diagnosticare e correggere errori sulle partizioni btrfs. Mentre Btrfs è stabile su una macchina stabile, è attualmente possibile corrompere irrimediabilmente un filesystem nel caso di crash o interruzione di alimentazione ai dischi che non gestiscono le richieste di flush correttamente.}}<br />
<br />
==== Ext4 ====<br />
[http://it.wikipedia.org/wiki/Ext4 Ext4] è un altro filsesystem che supporta gli SSD. Viene considerato stabile a partire dalla versione 2.6.28 ed è sufficientemente maturo per un uso quotidiano. Contrariamente a btrfs, ext4 non riconosce automaticamente la natura del disco ed è necessario abilitare esplicitamente il supporto al comando TRIM attraverso l'opzione di mount '''discard''' in [[fstab]] (oppure con tune2fs -o discard /dev/sdaX).<br />
Vedere la [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD documentazione ufficiale del kernel] per maggiori informazioni su ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156165Solid state drive (Italiano)2011-09-05T21:47:17Z<p>Lorenzog: /* Choice of Filesystem */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Posizionare /tmp in RAM ===<br />
Per sistemi con almeno 2 giga di memoria, posizionare /tmp in RAM è consigliato e anche facilmente realizzabile cancellando il contenuto della partizione fisica per /tmp e successivamente montarla su tmpfs (RAM) in {{Filename|/etc/fstab}}.<br />
La seguente linea ne è un esempio:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Posizonare i Profili del Browser in RAM ===<br />
E' possibile facilmente montare i profili dei browser come firefox, chromium, ecc. in RAM attraverso tmpfs e usare rsync per tenerli sincronizzati con i backup presenti su HDD. Per maggiori informazioni su questa procedura, vedere l'articolo [[Speed-up_Firefox_using_tmpfs|Velocizzare Firefox Usando tmpfs]]. Oltre all'ovvio incremento di velocità, in questo modo, sarà anche possibile prevenire cicli di lettura e scrittura sul proprio SSD.<br />
<br />
=== Compilare in /dev/shm ===<br />
Compilare intenzionalmente in /dev/shm è un'ottima idea per minimizzare questo problema. Per sistemi con almeno 4 Giga di memoria, la linea relativa a shm presente in {{Filename|/etc/fstab}} può essere modificata in modo da usare più della metà della memoria fisica disponibile grazie all'utilizzo dell'opzione size.<br />
<br />
Esempio di una macchina con 8 GiB di memoria fisica:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Scelta del Filesystem ===<br />
Esistono molte opzioni per i filesystem inclusi ext2, ext3, ext4, btrfs, ecc.<br />
<br />
==== Btrfs ====<br />
Il supporto a [http://it.wikipedia.org/wiki/Btrfs Btrfs] è stato incluso con la release principale del kernel Linux versione 2.6.29. Qualcuno sostiene che non sia abbastanza maturo per l'utilizzo in ambienti di produzione mentre altri già da tempo utilizzano questo potenziale successore di ext4. Notare che quando questo articolo è stato originariamente scritto (27-Giugno-2010), una versione stabile di btfrs non esiste. Vedere [http://www.madeo.co.uk/?p=346 questo] articolo di blog per maggiori informazioni su btfrs. Assicurarsi di leggere anche il [https://btrfs.wiki.kernel.org/index.php/Main_Page wiki di btfrs].<br />
<br />
{{Warning|Al momento in cui questo è stato scritto (21-Nov-2010) non esiste un utility fsck per diagnosticare e correggere errori sulle partizioni btrfs. Mentre Btrfs è stabile su una macchina stabile, è attualmente possibile corrompere irrimediabilmente un filesystem nel caso di crash o interruzione di alimentazione ai dischi che non gestiscono le richieste di flush correttamente.}}<br />
<br />
==== Ext4 ====<br />
[http://it.wikipedia.org/wiki/Ext4 Ext4] è un altro filsesystem che supporta gli SSD. Viene considerato stabile a partire dalla versione 2.6.28 ed è sufficientemente maturo per un uso quotidiano. Contrariamente a btrfs, ext4 non riconosce automaticamente la natura del disco ed è necessario abilitare esplicitamente il supporto al comando TRIM attraverso l'opzione di mount '''discard''' in [[fstab]] (oppure con tune2fs -o discard /dev/sdaX).<br />
Vedere la [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD documentazione ufficiale del kernel] per maggiori informazioni su ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156140Solid state drive (Italiano)2011-09-05T21:35:13Z<p>Lorenzog: /* Compiling in /dev/shm */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Posizionare /tmp in RAM ===<br />
Per sistemi con almeno 2 giga di memoria, posizionare /tmp in RAM è consigliato e anche facilmente realizzabile cancellando il contenuto della partizione fisica per /tmp e successivamente montarla su tmpfs (RAM) in {{Filename|/etc/fstab}}.<br />
La seguente linea ne è un esempio:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Posizonare i Profili del Browser in RAM ===<br />
E' possibile facilmente montare i profili dei browser come firefox, chromium, ecc. in RAM attraverso tmpfs e usare rsync per tenerli sincronizzati con i backup presenti su HDD. Per maggiori informazioni su questa procedura, vedere l'articolo [[Speed-up_Firefox_using_tmpfs|Velocizzare Firefox Usando tmpfs]]. Oltre all'ovvio incremento di velocità, in questo modo, sarà anche possibile prevenire cicli di lettura e scrittura sul proprio SSD.<br />
<br />
=== Compilare in /dev/shm ===<br />
Compilare intenzionalmente in /dev/shm è un'ottima idea per minimizzare questo problema. Per sistemi con almeno 4 Giga di memoria, la linea relativa a shm presente in {{Filename|/etc/fstab}} può essere modificata in modo da usare più della metà della memoria fisica disponibile grazie all'utilizzo dell'opzione size.<br />
<br />
Esempio di una macchina con 8 GiB di memoria fisica:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156139Solid state drive (Italiano)2011-09-05T21:32:13Z<p>Lorenzog: /* Locate Browser Profiles in RAM */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Posizionare /tmp in RAM ===<br />
Per sistemi con almeno 2 giga di memoria, posizionare /tmp in RAM è consigliato e anche facilmente realizzabile cancellando il contenuto della partizione fisica per /tmp e successivamente montarla su tmpfs (RAM) in {{Filename|/etc/fstab}}.<br />
La seguente linea ne è un esempio:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Posizonare i Profili del Browser in RAM ===<br />
E' possibile facilmente montare i profili dei browser come firefox, chromium, ecc. in RAM attraverso tmpfs e usare rsync per tenerli sincronizzati con i backup presenti su HDD. Per maggiori informazioni su questa procedura, vedere l'articolo [[Speed-up_Firefox_using_tmpfs|Velocizzare Firefox Usando tmpfs]]. Oltre all'ovvio incremento di velocità, in questo modo, sarà anche possibile prevenire cicli di lettura e scrittura sul proprio SSD.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156136Solid state drive (Italiano)2011-09-05T21:28:23Z<p>Lorenzog: /* Locate /tmp in RAM */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Posizionare /tmp in RAM ===<br />
Per sistemi con almeno 2 giga di memoria, posizionare /tmp in RAM è consigliato e anche facilmente realizzabile cancellando il contenuto della partizione fisica per /tmp e successivamente montarla su tmpfs (RAM) in {{Filename|/etc/fstab}}.<br />
La seguente linea ne è un esempio:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [[Speed-up_Firefox_using_tmpfs|Speed-up Firefox Using tmpfs]] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156132Solid state drive (Italiano)2011-09-05T21:25:21Z<p>Lorenzog: /* SSD Benchmarking */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [[Speed-up_Firefox_using_tmpfs|Speed-up Firefox Using tmpfs]] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== Misurare le Prestazioni degli SSD ==<br />
Vedere l'articolo [[SSD Benchmarking]] per una procedura generale per misurare le prestazioni del proprio SSD o per vedere le prestazioni di alcuni SSD presenti nel database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156131Solid state drive (Italiano)2011-09-05T21:23:28Z<p>Lorenzog: /* Firmware Updates */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [[Speed-up_Firefox_using_tmpfs|Speed-up Firefox Using tmpfs]] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Aggiornamenti del Firmware ==<br />
=== OCZ ===<br />
OCZ ha una utility da riga di comando disponibile per linux (i686 e x86_64) sul proprio forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool qui].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156130Solid state drive (Italiano)2011-09-05T21:21:56Z<p>Lorenzog: /* The noatime Mount Flag */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== L'Opzione di Mount noatime ===<br />
Assegnare l'opzione '''noatime''' alle partizioni che risiedono su SSD. Vedere la sezione [[#Mount_Flags|Opzioni di Mount]] più avanti per maggiori informazioni.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [[Speed-up_Firefox_using_tmpfs|Speed-up Firefox Using tmpfs]] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=156128Solid state drive (Italiano)2011-09-05T21:19:34Z<p>Lorenzog: /* Intelligent Partition Scheme */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[SSD_Memory_Cell_Clearing#Post_Process_Observation|using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Schema di Partizionamento Intelligente ===<br />
Valutare di spostare la partizione dove risiede /var su un disco fisico del sistema piuttosto che sul SSD per prevenire l'usura a causa di letture e scritture. La maggior parte degli utenti può tenere soltanto / e /home sul SSD (anche /boot) posizionando /var e /tmp su un HDD fisico. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
Se l'SSD è l'unica periferica di memorizzazione presente sul sistema (nessun HDD), valutare di preparare una partizione dedicata per /var in modo da permettere un miglior recupero del sistema, per esempio nel caso che un programma difettoso utilizzi tutto lo spazio presente su / o che tutto lo spazio venga occupato dai log.<br />
<br />
Un'altra possibilità intelligente è quella di posizionare /tmp in RAM se il sistema ha sufficiente memoria. Vedere la prossima sezione per questa opzione.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [[Speed-up_Firefox_using_tmpfs|Speed-up Firefox Using tmpfs]] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [[#Compiling_in_.2Fdev.2Fshm|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=154394Solid state drive (Italiano)2011-08-30T14:28:11Z<p>Lorenzog: /* SSD Memory Cell Clearing */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== Pulizia delle Celle di Memoria degli SSD ===<br />
In alcune occasioni, si potrebbe volere resettare completamente le celle di un SSD allo stesso stato iniziale che avevano al momento dell'installazione per ripristinarle alle loro [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 prestazioni di fabbrica in scrittura]. Le prestazioni in scrittura tendono a degradare con l'andare del tempo anche su SSD con supporto TRIM. Il TRIM si limita a salvaguardare contro la cancellazione dei file, non contro le sostituzioni come nel caso di un salvataggio incrementale.<br />
<br />
La prcoedura di reset è facilmente realizzabile in tree passi indicati sull'articolo del wiki [[SSD Memory Cell Clearing]].<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=154392Solid state drive (Italiano)2011-08-30T14:13:36Z<p>Lorenzog: /* Swap Space on SSDs */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Spazio di Swap su SSD ===<br />
<br />
E' possibile posizionare la partizione di swap su un SSD. Considerare comunque che i sistemi desktop moderni che hanno generalmente piu di 2 GiB di memoria raramente utilizzando lo spazio di swap. L'eccezione degna di nota sono i sistemi che utilizzano la funzionalità di ibernazione. Il seguente è l'impostazione consigliata per una partizione di Swap su SSD che riduce lo "swapiness" del sistema in modo da evitare le scritture in swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
O più semplicemente modificare {{Filename|/etc/sysctl.conf}} come indicato nell'articolo del wiki [[Maximizing_performance#Swappiness|Maximizing Performance]].<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=154391Solid state drive (Italiano)2011-08-30T14:05:26Z<p>Lorenzog: /* I/O Scheduler */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== Scheduler I/O ===<br />
<br />
{{Note|Questa configurazione non dovrebbe essere necessaria dal momento che lo scheduler cfq controlla se il drive non è rotazionale e si comporta in maniera corretta per gli SSD.}}<br />
<br />
Considerare di passare dallo scheduler di default, che in Arch è cfs (completely fair queuing), a scheduler noop o deadline per un SSD. Con l'utilizzo dello scheduler noop, per esempio, le richieste vengono processate semplicemente in ordine di arrivo, senza nessuna considerazione su dove i dati risiedono fisicamente sul disco. Questa opzione è pensata per essere vantaggiosa per gli SSD dal momento che il tempo di accesso è identico per tutti i settori dell'SSD.<br />
<br />
Comunque, per alcuni SSD, in particolare i primi basati su JMicron, ci potrebbero essere prestazioni migliori con lo scheduler di default (vedere [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ qui] per una situazione del genere); per questi, nonostante i tempi di accesso siano simili per tutti i settori, il carico per gli accessi casuali è sufficientemente grande da superare qualsiasi vantaggio. Se il proprio SSD è stato costruito nell'ultimo anno o è stato costruito da Intel, questo probabilmente non è il vostro caso.<br />
<br />
Per maggior informazioni sugli scheduler vedere [http://www.linux-mag.com/id/7564/1 questo] articolo del Linux Magazine (è necessaria la registrazione).<br />
<br />
Per informazione sullo scheduler di default con gli SSS: https://bugs.archlinux.org/task/22605<br />
<br />
Su Arch lo scheduler cfq è abilitato di default. E possibile verificarlo osservando il contenuto di<br />
/sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
Lo scheduler attualmente utilizzato è indicato fra parentesi quadre.<br />
<br />
Ci sono diverse possibilità per cambiare il tipo di scheduler.<br />
<br />
{{Note|Cambiare il tipo di scheduler soltanto per gli SSD. Mantener lo scheduler cfq per tutti gli altri HDD fisici è ''altamente'' consigliato.}}<br />
<br />
===== Usare il filesystem virtuale sys =====<br />
Questo metodo è da preferirsi quando il sistema system ha diverse periferiche di memorizzazione (ad esempio un SSD e un HDD)<br />
Aggiungere la seguente linea in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Dove X è la lettera del SSD.<br />
<br />
===== Parametro del Kernel =====<br />
Se l'unica periferica di memorizzazione nel sistema è un SSD, valutare di impostare lo scheduler di I/O per l'intero sistema tramite il parametro del kernel elevator:<br />
elevator=noop<br />
<br />
Per esempio, con GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
o con GRUB2, in {{Filename|/etc/default/grub}}: (ricordarsi di eseguire update-grub successivamente)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=154390Solid state drive (Italiano)2011-08-30T13:37:14Z<p>Lorenzog: /* Considerazioni speciali per partizioni logiche */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni Speciali per Partizioni Logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=154389Solid state drive (Italiano)2011-08-30T13:36:45Z<p>Lorenzog: /* Special Considerations for RAID0 Setups with Multiple SSDs */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni speciali per partizioni logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Considerazioni Speciali per RAID0 con SSD Multipli ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=154388Solid state drive (Italiano)2011-08-30T13:35:35Z<p>Lorenzog: /* Special Considerations for Logical Partitions */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Considerazioni speciali per partizioni logiche ======<br />
<br />
---Segnaposto per contenuti.<br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=154387Solid state drive (Italiano)2011-08-30T13:34:45Z<p>Lorenzog: /* Detailed Usage Example */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Esempio di Utilizzo Dettagliato ======<br />
<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un SSD Intel X25-M con una singola partizione Linux da 12 GiB. Non è in nessun modo il metodo definitivo per farlo nè gli switch utilizzati per avviare fdisk in questo specifico esempio hanno necessariamente i valori corretti per altri modelli e marche di SSD!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
Il resto dell'SSD è stato partizionato in maniera simile utilizzando in totale due partizioni. Ecco come si presenta l'output del comando list di fdisk:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
E del comando di fdisk -lu:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Prestare attenzione all'ultimo step per testare lo stato di salute. Se le testine e i settori/traccia non rimangono 32/32, questo è dovuto o ad un bug in fdisk o a una ragione sconosciuta. Vedere la pagine del wiki [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] per una soluzione.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153652Solid state drive (Italiano)2011-08-27T16:06:19Z<p>Lorenzog: /* Using MBR - DEPRECATED METHOD - Using GPT is Recommended */ - Summary</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Usare MBR - METODO DEPRECATO - L'utilizzo di GPT è Raccomandato ====<br />
<br />
L'utilità di sistema Linux fdisk, comunque, continua ad utilizzare il sistema C-H-S dove gli utenti possono definire un qualsiasi numero di testine e settori (i cilindri sono calcolati automaticamente in base alla capacità del dispositivo), con partizioni che iniziano e finiscono sempre allo stesso intervallo di testine e cilindri. '''Quindi, è necessario scegliere un numero di testine e settori sottomultipli della dimensione dell' EBS del SSD.''' Questo viene ottenuto impostando il numero delle testine (o tracce per cilindro) e i settori (per traccia) in modo da coincidere con l'EBS.<br />
<br />
Ted Tso raccomanda di utilizzare un impostazione di [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) ottenendo un allineamento di (2^8*512=) 128 KiB:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
Mentre altri raccomandano di utilizzare un impostazione di [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] ottenendo un allineamento di (2^10*512=) 512 KiB:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
Come funzionano questi calcoli? Il numero per l'allineamento è la più grande potenza di due che divide le posizioni del cilindro di confine sul disco. La dimensione in byte dei cilindri è H*S*512 = (traccie per cilindro) * (settori per traccia) * (dimensione dei settori). Fattorializzare H, S e la dimensione dei settori (512=2^9) in fattori primi e prendere tutti i 2s. Nel primo caso descritto è necessario ignorare il fattore che non è potenza di due, 7^2=49.<br />
<br />
{{Note|Per motivi di compatibilità MS-DOS, una partizione che inizi dal primo cilindro non deve conto di un traccia, riducendo il suo allineamento a livello della traccia (4k per -S 56 e 16k per -S 32). Il modo più semplice per allineare la prima partizione è farla iniziare al cilindro 2 piuttosto che al cilindro 1 come di default come visto nell'esempio precedente.}}<br />
<br />
===== Schema di Utilizzo di Fdisk =====<br />
*Avviare fdisk usando i valori corretti per H e S specifici per il proprio SSD come descritto precedentemente. <br />
*Se l'SSD è nuovo, creare una nuova partizione vuota DOS con il comando 'o'.<br />
*Creare una nuova partizione con il comando 'n'(primary type/1st partition).<br />
*Iniziare dal settore 2 invece che dal settore 1 per assicurare compatibilità con MS-DOS se questa è richiesta, altrimenti accettare il valore di default.<br />
*Usare il formato +xG per estendere la partizione di x gigabyte.<br />
*Cambiare l'id del tipo di partizione dal valore di default Linux (type 83) al tipo desiderato tramite il comando 't'. Questo è un passaggio opzionale per gli utenti che vogliano creare un altro tipo di partizione come ad esemepio swap, NTFS, ecc. Una lista complete delle alternative disponibili è disponibile tramite il comando 'l'.<br />
*Creare altre partizione seguendo lo stesso procedimento.<br />
*Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
<br />
Quando finito, gli utenti possono formattare le loro nuove partizioni con 'mkfs.x /dev/sdXN' dove x è il tipo di filesystem, X e la lettera del drive e N e il numero della partizione.<br />
Il seguente esempio formatta la prima partizione del primo disco in ext4 utilizzando le opzioni di default definite in {{Filename|/etc/mke2fs.conf}}:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|L'utilizzo del comando mkfs può essere pericoloso dal momento che un semplice errore può causare la formattazione della partizione SBAGLIATA e la perdita di dati. Controllare TRE volte la partizione scelta prima di premere il tasto Enter!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153647Solid state drive (Italiano)2011-08-27T15:36:07Z<p>Lorenzog: /* Mount Flags */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Opzioni di Mount===<br />
Ci sono alcune opzioni chiave di mount da usare per le partizioni su SSD in {{filename|/etc/fstab}}.<br />
<br />
*'''noatime''' - Accessi in lettura al filesystem non causeranno più un aggiornamento alle informzioni di atime associate al file. L'importanza dell'impostazione noatime consiste nell'eliminazione della necessità del sistema di effettuare accessi in scrittura al filesystem anche per la lettura di file. Dal momento che le scritture sono costose come descritto nella precedente sezione, in questo modo è possibile avere un discreto aumento di prestazioni. Notare che nonostante questa opzione il tempo dell'ultima modifica di un file continua ad essere aggiornato.<br />
*'''discard''' - L'opzione discard abilita i benefici del comando TRIM purchè si utilizzi una versione del kernel >=2.6.33. Questa impostazione non funzione con ext3, l'utilizzo dell'opzione discard con una partizione di root con filesystem ext3 ne determinerà l'accesso in sola lettura.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|E' possibile impostare l'opzione discard anche con tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|E' fondamentale che gli utenti impostino il controller che pilota l'SSD in AHCI mode (no in IDE mode) per assicurarsi che il kernel sia in grado di utilizzare il comando TRIM.}} <br />
{{Warning|Gli utenti di devono assicurare di utilizzare una versione del kernel maggiore o uguale alla 2.6.33 e che il proprio SSD supporti il comando TRIM prima di provare a montare una partizione con l'opzione discard. Altrimenti sono possibili perdite di dati!.}}<br />
{{Warning|Con l'utilizzo di un SSD OCZ Vertex II (che supporta TRIM) e il kernel 2.6.37.4 alcuni utenti su Arch hanno avuto problemi con l'opzione '''discad''': tutti le modifiche fatte al filesystem sono scomparse dopo un riavvio. Secondo [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 questo], l'opzione '''discard''' è disattivata di default perchè non sufficientemente stabile.}}<br />
<br />
====Considerazioni speciali per computer Mac====<br />
<br />
Per default, il firmware APPLE imposta la modalità SATA in IDE mode (piuttosto che in AHCI) all'avvio di ogni sistema operativo ad eccezione di Mac OS. E' comunque semplice ritornare nella modalità AHCI se si utilizza un controller SATA Intel e [[GRUB2]].<br />
<br />
Per prima cosa determinare l'identificativo PCI del proprio controller SATA. Eseguire il comando:<br />
# lspci -nn<br />
e trovare la linea che indica "SATA AHCI Controller". L'identificativo PCI è fra parentesi quadre e dovrebbe apparire come 8086:27c4 (anche se le ultime cifre potrebbero differire).<br />
<br />
Adesso modificare /boot/grub/grub.cfg aggiungendo la linea<br />
# setpci -d 8086:27c4 90.b=40<br />
immediatamente prima la linea "set root" di ogni sistema operativo per il quale si vuole abilitare la modalita AHCI. Assicurarsi di sostituire con l'identificativo PCI appropriato.<br />
<br />
(fonte: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153639Solid state drive (Italiano)2011-08-27T15:12:49Z<p>Lorenzog: /* Encrypted partition */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Partizioni cifrate===<br />
<br />
Se si utilizza cryptsetup, definire un payload sufficiente([http://www.spinics.net/lists/dm-crypt/msg02421.html vedere qui]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
Ma ricordarsi che la funzionalità DISCARD/TRIM non è supportata da device-mapper (anche se è in lavorazione [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 vedere qui])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153445Solid state drive (Italiano)2011-08-26T13:44:18Z<p>Lorenzog: /* = Esempio di Utilizzo Dettagliato */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
==== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153444Solid state drive (Italiano)2011-08-26T13:43:31Z<p>Lorenzog: /* Detailed Usage Example */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
===== Esempio di Utilizzo Dettagliato ====<br />
{{Note|La seguente sezione ha lo scopo di illustrare il processo di partizionamento di un Crucial C300 Real SSD con una singola partizione: 10GiB, partizione Linux. Anche se si dovrebbe applicare ad ogni SSD, adattare al proprio schema di partizionamento. Ancora, non dimenticare di aggiungere una partizione di 1MiB di tipo BIOS boot come prima partizione se necessario.}}<br />
<br />
Installare gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Eseguire gdisk sul proprio SSD assunto essere /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Creare una nuova tabella di partizioni GUID:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creare le partizioni:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Risultato:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Scrivere la tabella delle partizioni ed uscire:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Adesso è possibile creare il file system seguendo la maniera usuale:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153434Solid state drive (Italiano)2011-08-26T13:32:37Z<p>Lorenzog: /* Using GPT - RECOMMENDED METHOD */ - summary</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
=== Usare GPT - METODO RACCOMANDATO ===<br />
[[GPT]] è uno stile di partizionamento alternativo e attuale. Il tool compatibile con GPT equivalente a fdisk, gdisk, è in grado di allineare automaticamente le partizioni su un blocco base di dimensioni di 2048 settori (o 1024KiB) compatibile con la gran parte degli SSD se non tutti. Anche GNU parted supporta GPT, ma è [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 meno intuitivo] per allineare le partizioni.<br />
<br />
Schema di Utilizzo di Gdisk:<br />
<br />
* Installare gdisk dal repository extra.<br />
* Avviare gdisk passando come argomento proprio SSD<br />
* Se l' SSD è nuovo o si vuole reinizializzare, creare una nuova tabella delle partizioni GUID (GPT) con il comando 'o'. <br />
* Creare una nuova partizione con il comando 'n' (primary type/1st partition).<br />
* Assumendo che la partizione è nuova, gdisk utilizzerà l'allineamento più alto possibile. Altrimenti sceglierà la più grande potenza di due che divide tutti gli scarti delle partizioni.<br />
* Se si sceglie di iniziare su un settore precedente al 2048esimo gdisk sposterà automaticamente l'inizio della partizione al 2048esimo settore. Questo per assicurarsi un allineamento su 2048 settori (dal momento che un settore è 512B, questo è un allineamento di 1024 KiB che dovrebbe contemplare ogni possibile ESB degli SSD). <br />
* Usare il formato +x{M,G} per estendere la partizione di x megabyte o gigabyte. Se si sceglie una dimensione che non è un multiplo della dimensione di allineamento (1024kiB) gdisk adatterà la partizione al più vicino e piccolo multiplo.<br />
* Selezionare il tipo della partizione, il default 'Linux/Windows data' (code 0700) dovrebbe andar bene per la maggior parte degli utilizzi. Premere L per vedere una lista dei tipi disponibili.<br />
* Creare altre partizione seguendo lo stesso procedimento.<br />
* Scrivere la tabella delle partizioni sul disco e uscire con il comando 'w'.<br />
* Creare i filesystem normalmente.<br />
<br />
{{Warning|Se si ha in programma di utilizzare il disco come disco di boot su un sistema basato sul BIOS (la maggior parte dei sistemi ad eccezione dei computer APPLE e di alcuni rari modelli di schede madri con chipset INTEL) è necessario creare, possibilmente all'inizio del disco, una partizione di 1MiB di tipo BIOS boot partition (code ef02). Questo è necessario per l'utilizzo di [[GRUB2]], mentre per [[Syslinux]] è sufficiente preparare una partizione di /boot distinta. Vedere [[GPT]] per maggiori informazioni.}}<br />
<br />
{{Warning|GRUB legacy non supporta lo schema di partizionamento GUID, si deve usare [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|Se si ha intenzione di avere un dual boot con Windows (XP, Vista or 7) non usare GPT dal momento che non supportano il boot da dischi GPT! E' necessario usare il metodo deprecato del MBR descritto successivamente. Questa limitazione non si applica se si utilizza un sistema EFI e Windows Vista (64bits) o Seven (sia 32 che 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153421Solid state drive (Italiano)2011-08-26T13:05:32Z<p>Lorenzog: /* Descrizione ad alto livello */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
Se le partizioni non sono allineate per iniziare ad un multiplo dell'EBS (per esempio 512 KiB), l'allineamento del file system è soltanto un esercizio senza senso in quanto l'intero allineamento è rovinato dallo scarto iniziale della partizione. Generalmente, i dischi fissi sono indirizzati tramite ''cilindri'', ''testine'' e ''settori'' nei quali i dati vengono letti e scritti. Questi rappresentano rispettivamente la posizione radiale, la testina del disco (piatto e lato) e la posizione assiale dei dati. Con l' LBA (logical block addressing), questo non è più vero. L'intero disco fisso è indirizzato come un flusso continuo di dati.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=153416Solid state drive (Italiano)2011-08-26T12:59:07Z<p>Lorenzog: /* Partition Alignment */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Allineamento della partizione ===<br />
===== Descrizione ad alto livello =====<br />
'''Un corretto allineamento della partizione è essenziale per prestazione ottimali e longevità.''' La chiave per l'allineamento è partizionare almeno alla dimensione dell' EBS (erase block size) del SSD.<br />
<br />
{{Note|L'EBS è per lo più dipendente dal costruttore; una ricerca su Google sul modello di interesse potrebbe essere un'ottima idea! L'Intel X25-M per esempio si presuppone avere un EBS di 512 KiB, ma Intel non ha ancora pubblicato niente di ufficiale a riguardo. }}<br />
{{Note|Se non si conosce l'EBS del proprio SSD, è comunque possibile usare una dimensione di 512 KiB (o 1024 KiB se si vuole essere sicuri e non ci si preoccupa di perdere il primo MiB del proprio disco). Queste dimensioni sono maggiori o uguali di tutti i correnti EBS. Allineare le partizioni per l'EBS produrrà partizioni allineate anche per dimensioni più piccole. Windows 7 e Ubuntu utilizzano questo stratagemma per ottimizzare le partizioni per lavorare con gli SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150728Solid state drive (Italiano)2011-08-05T16:05:56Z<p>Lorenzog: /* Consigli per l'acquisto */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di un SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita degli SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150727Solid state drive (Italiano)2011-08-05T16:05:03Z<p>Lorenzog: /* Limitazioni */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partizioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per gli SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di una SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita della SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150726Solid state drive (Italiano)2011-08-05T16:02:13Z<p>Lorenzog: /* Tips for Maximizing SSD Performance */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partitioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per le SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di una SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita della SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Consigli per massimizzare le prestazioni degli SSD==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150725Solid state drive (Italiano)2011-08-05T15:59:17Z<p>Lorenzog: /* Pre-Purchase Considerations */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partitioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per le SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Consigli per l'acquisto==<br />
Ci sono alcune caratteristiche chiave da considerare prima di procedere all'acquisto di una SSD attuale.<br />
===Caratteristiche chiave===<br />
*Il supporto nativo al [http://en.wikipedia.org/wiki/TRIM TRIM] è una caratteristica fondamentale sia per prolungare la vita della SSD sia per ridurre la perdita di prestazioni in scrittura nel tempo.<br />
*Comprare SSD della giusta dimensione è fondamentale. Con qualsiasi filesystem, l'occupazione massima di ogni partizione non deve superare il 75% per garantirne un uso efficiente da parte del kernel.<br />
<br />
===Approfondimenti===<br />
Questa sezione non intende essere omni comprensiva ma comprende alcune analisi importanti<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150724Solid state drive (Italiano)2011-08-05T15:52:55Z<p>Lorenzog: /* Limitazioni */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. L'accesso alla flash di basso livello che potrebbe essere usato dai moderni sistemi operativi per ottimizzarne l'accesso è nascosto da un livello di traslazione flash.<br />
*Partitioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura.Le celle per uso consumer MLC prodotte con processo a 50nm possono gestire ciascuna 10000 scritture, quelle a 35nm generalmente gestiscono 5000 scritture e quelle a 25nm circa 3000 (processi di produzione più piccoli significano maggiore densità e minor prezzo). Se le scritture sono correttamente organizzate, non sono troppo piccole, e sono allineate con le celle, questo si traduce in volume di scritture totali supportato per le SSD multiplo della propria capacità. Volumi di scritture quotidiani devono essere bilanciati in relazione all'aspettativa di durata.<br />
*I firmware e i controllori sono complessi. Occasionalmente possono avere dei bug. Quelli più moderni consumano una quantità di energia paragonabile agli HDD classici. Essi [https://lwn.net/Articles/353411/ implementano] l'equivalente di un file system strutturato su log con una gestione dello spazio non più utilizzato. Essi traducono i tradizionali comandi SATA pensati per driver rotatori. Alcuni di essi sono capaci di effettuare la compressione in tempo reale. Gestiscono scritture ripetute su l'intera superficie della flash, per prevenire l'usura prematura delle celle. Sono anche in grado di unire più scritture insieme in modo che piccole scritture non diano luogo a lunghi cicli di cancellazioni su celle grandi. Infine hanno la capacità di spostare le celle che contengono dati in modo da prevenirne la perdita nel tempo.<br />
*Le prestazioni possono degradare con lo spazio occupato. La gestione dello spazio non più utilizzato non è universalmente ben implementata e lo spazio libero non sempre è organizzato su celle interamente vuote<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150599Solid state drive (Italiano)2011-08-03T17:19:17Z<p>Lorenzog: /* Introduction */</p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduzione==<br />
I Drive a Stato Solido non sono componenti Plug&Play. Sono necessari accorgimenti particolari come l'allineamento delle partizioni, la scelta del file system, il supporto a TRIM, etc. per impostare gli SSD per le prestazioni ottimali. Questo articolo tenta di spiegare i passaggi chiave per permettere agli utenti di ottenere il massimo dai propri SSD sotto Linux. Gli utenti sono incoraggiati a leggere questo articolo per intero prima di mettere in pratica le impostazioni dal momento che il contenuto è organizzato per argomento e non segue necessariamente un ordine sistematico o cronologico. <br />
<br />
{{Note|Questo articolo è orientato verso gli utenti Linux, ma la maggior parte del suo contenuto è sensibile anche per i nostri amici che utilizzano Windows o Mac OS X.}}<br />
===Vantaggi rispetto agli Hard Disk===<br />
*Velocità di lettura maggiore - 2 - 3 volte più veloce di un HDD desktop attuale (7,200 RPM con interfaccia SATA2).<br />
*Velocità di lettura costante - Nessun decremento di velocità in lettura su tutta l'interezza del drive. Le prestazioni degli HDD tendono a diminuire con il movimento della testina dalle parti più esterne a quelle più interne dei dischi<br />
*Tempo di accesso minimo - Circa 100 volte più veloce di un HDD. Per esempio, 0.1 ms (100 ns) contro 12-20 ms (12,000-20,000 ns) per HDD desktop.<br />
*Alto grado di affidabilità.<br />
*Nessuna parte in movimento.<br />
*Produzione di calore minima.<br />
*Consumo di corrent elettrica minimo - Frazioni di un Watt in condizione di riposo e 1-2 Watt in lettura/scrittura contro 10-30 Watt for un HDD a seconda delle rotazioni RPM.<br />
*Leggerezza - ideale per i computer portatili.<br />
<br />
===Limitazioni===<br />
*Costo per capacità (dollari per GB, contro spiccioli per GB per HDD classici).<br />
*Capacità dei modelli in commercio inferiore rispetto agli HDD classici.<br />
*Celle di memoria grandi richiedono diverse ottimizzazioni dei file system rispetto ai driver rotatori. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitioni e filesystem necessitano di ottimizzazioni specifiche. La dimensione della pagina e la dimensione della pagina di eliminazione non sono riconosciute automaticamente.<br />
*Le celle sono sottoposte a usura. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes aren't amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell doesn't lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection isn't universally well implemented, meaning freed space isn't always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150596Solid state drive (Italiano)2011-08-03T16:58:44Z<p>Lorenzog: </p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzano SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using both Windows and Mac OS X.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - No decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - Approx. 100x faster than an HDD. For example, 0.1 ms (100 ns) vs. 12-20 ms (12,000-20,000 ns) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - Fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (dollars per GB, vs. pennies per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size aren't autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes aren't amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell doesn't lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection isn't universally well implemented, meaning freed space isn't always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150595Solid state drive (Italiano)2011-08-03T16:58:03Z<p>Lorenzog: </p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start|Sommario}}<br />
{{Article summary text|Questo articolo copre molti aspetti degli SSD (drive a stato solido) in relazione a Linux ; comunque, i principi di base e gli insegnamenti chiave presentati sono abbastanza generali per essere applicati anche agli utenti che utilizzono SSD con altri sistemi operativi come la famiglia dei prodotti Windows o quelli MacOS X. A parte le informazioni appena menzionate gli utenti Linux potranno beneficiare delle ottimizzazioni qui presentate.}}<br />
{{Article summary heading|Articoli Correlati}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using both Windows and Mac OS X.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - No decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - Approx. 100x faster than an HDD. For example, 0.1 ms (100 ns) vs. 12-20 ms (12,000-20,000 ns) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - Fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (dollars per GB, vs. pennies per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size aren't autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes aren't amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell doesn't lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection isn't universally well implemented, meaning freed space isn't always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150594Solid state drive (Italiano)2011-08-03T16:49:16Z<p>Lorenzog: </p>
<hr />
<div>[[Category: Storage (Italiano)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principals and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as MacOS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.}}<br />
{{Article summary heading|Related Articles}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using both Windows and Mac OS X.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - No decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - Approx. 100x faster than an HDD. For example, 0.1 ms (100 ns) vs. 12-20 ms (12,000-20,000 ns) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - Fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (dollars per GB, vs. pennies per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size aren't autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes aren't amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell doesn't lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection isn't universally well implemented, meaning freed space isn't always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive_(Italiano)&diff=150593Solid state drive (Italiano)2011-08-03T16:48:14Z<p>Lorenzog: Created page with "Category: Storage (English) {{i18n|Solid State Drives}} {{translateme}} {{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese...."</p>
<hr />
<div>[[Category: Storage (English)]]<br />
{{i18n|Solid State Drives}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
{{Article summary start}}<br />
{{Article summary text|This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principals and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as MacOS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.}}<br />
{{Article summary heading|Related Articles}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using both Windows and Mac OS X.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - No decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - Approx. 100x faster than an HDD. For example, 0.1 ms (100 ns) vs. 12-20 ms (12,000-20,000 ns) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - Fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (dollars per GB, vs. pennies per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size aren't autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes aren't amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell doesn't lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection isn't universally well implemented, meaning freed space isn't always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=150592Solid state drive2011-08-03T16:45:57Z<p>Lorenzog: Added i18n</p>
<hr />
<div>[[Category: Storage (English)]]<br />
{{i18n|Solid State Drives}}<br />
{{Article summary start}}<br />
{{Article summary text|This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principals and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as MacOS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.}}<br />
{{Article summary heading|Related Articles}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to setup SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using both Windows and Mac OS X.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - No decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - Approx. 100x faster than an HDD. For example, 0.1 ms (100 ns) vs. 12-20 ms (12,000-20,000 ns) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - Fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (dollars per GB, vs. pennies per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size aren't autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes aren't amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell doesn't lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection isn't universally well implemented, meaning freed space isn't always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and testing TIM in linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Partition Alignment ===<br />
===== High-level Overview =====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' Key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD. <br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If you don't know the EBS of your SSD, you can still use a size of 512 KiB (or 1024 KiB if you want to be sure and you don't care loosing the first MiB of your disk). Those numbers are greater or equal than all the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows Seven and Ubuntu "optimizes" partitions to work with SSD.}}<br />
<br />
If the partitions aren't aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
==== Using GPT - RECOMMENDED METHOD ====<br />
[[GPT]] is an alternative, contemporary partitioning style. The GPT-able tool equivalent to fdisk, gdisk, can perform partitions alignment automatically on a 2048 sectors (or 1024KiB) block size base which should be compatible with the vast majority of SSD if not all. GNU parted also support GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions.<br />
<br />
Gdisk Usage Summary:<br />
<br />
* Install gdisk from the extra repository.<br />
* Simply start gdisk against your SSD.<br />
* If the SSD is brand new or if you want to start over, create a new empty GUID partition table (aka GPT) with the 'o' command.<br />
* Create a new partition with the 'n' command (primary type/1st partition).<br />
* Assuming your partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If you choose to start on a sector before the 2048th gdisk will automatically shift your partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the +x{M,G} format to extend the partition x megabytes or gigabytes, if you choose a size that is not a multiple of the alignment size (1024kiB) gdisk will shrink the partition to the nearest inferior multiple).<br />
* Select the partition's type id, the default, 'Linux/Windows data' (code 0700), should be fine for most use. Press L to show the codes list.<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the 'w' command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If you plan to use the disk as boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) you may have to create, preferably at the disk's beginning, a 1MiB partition with the type BIOS boot partition (code ef02). This is necessary if you intend to use [[GRUB2]], but for [[Syslinux]] it's enough to make a separate /boot partition at this point. See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, you have to use [[burg]], [[GRUB2]] or [[Syslinux]].}}<br />
<br />
{{Warning|If you plan to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk! You will need to use the depreciated MBR method described below! This limitation doesn't apply if you run an EFI-powered machine and Windows Vista (64bits) or Seven (both 32 and 64bits).}}<br />
<br />
===== Detailed Usage Example =====<br />
{{Note|The following section is meant to be illustrative of the process of partitioning a Crucial C300 Real SSD with a single partitions: 10GiB, Linux partition. Even if it should work on any SSD, with adapt it to your own partition scheme. Again, don't forget to add a 1MiB BIOS boot partition as the first partition if needed.}}<br />
Install gdisk:<br />
# pacman -S gptfdisk<br />
<br />
Run gdisk against your SSD which we will assume to be /dev/sda:<br />
<pre>[root@archlinux ~]# gdisk /dev/sda<br />
GPT fdisk (gdisk) version 0.6.13<br />
<br />
Partition table scan:<br />
MBR: not present<br />
BSD: not present<br />
APM: not present<br />
GPT: not present<br />
<br />
Creating new GPT entries.<br />
</pre><br />
<br />
Now create a new GUID partition table:<br />
<pre>Command (? for help): o<br />
This option deletes all partitions and creates a new protective MBR.<br />
Proceed? (Y/N): y</pre><br />
<br />
Creating partition:<br />
<pre>Command (? for help): n<br />
Partition number (1-128, default 1): #pressed enter to accept default#<br />
First sector (34-125045424, default = 34) or {+-}size{KMGTP}: #pressed enter to accept default#<br />
Information: Moved requested sector from 34 to 2048 in<br />
order to align on 2048-sector boundaries.<br />
Use 'l' on the experts' menu to adjust alignment<br />
Last sector (2048-125045424, default = 125045424) or {+-}size{KMGTP}: +10G <br />
Current type is 'Linux/Windows data'<br />
Hex code or GUID (L to show codes, Enter = 0700): #pressed enter to accept default#<br />
Changed type of partition to 'Linux/Windows data'<br />
</pre><br />
<br />
Result:<br />
<pre>Command (? for help): p<br />
Disk /dev/sda: 125045424 sectors, 59.6 GiB<br />
Logical sector size: 512 bytes<br />
Disk identifier (GUID): A89B4292-8ED7-40CB-BD45-58A160E090EE<br />
Partition table holds up to 128 entries<br />
First usable sector is 34, last usable sector is 125045390<br />
Partitions will be aligned on 2048-sector boundaries<br />
Total free space is 2014 sectors (1007.0 KiB)<br />
<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 20973567 10.0 GiB 0700 Linux/Windows data</pre><br />
<br />
Write the partition table and exit:<br />
<pre>ommand (? for help): w<br />
<br />
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING<br />
PARTITIONS!!<br />
<br />
Do you want to proceed, possibly destroying your data? (Y/N): y<br />
OK; writing new GUID partition table (GPT).<br />
Warning: The kernel is still using the old partition table.<br />
The new table will be used at the next reboot.<br />
The operation has completed successfully.<br />
[root@archlinux ~]#</pre><br />
<br />
Now create the file system as usual:<pre># mkfs.ext4 /dev/sda1</pre><br />
<br />
==== Using MBR - DEPRECATED METHOD - Using GPT is Recommended ====<br />
<br />
The Linux utility fdisk, however, still uses a virtual C-H-S system where users can define any number of heads and sectors (the cylinders are calculated automatically from the drive's capacity), with partitions always starting and ending at intervals of heads x cylinders. '''Thus, one needs to choose a number of heads and sectors of which the SSD's erase block size is a multiple.''' This is accomplished by setting the number of heads (or tracks per cylinder) and sectors (per track) to coincide with the EBS.<br />
<br />
Ted Tso recommends using a setting of [http://ldn.linuxfoundation.org/blog-entry/aligning-filesystems-ssd%E2%80%99s-erase-block-size 224*56] (=2^8*49) which results in (2^8*512=) 128 KiB alignment:<br />
<br />
# fdisk -H 224 -S 56 /dev/sdX<br />
<br />
While others advocate a setting of [http://www.nuclex.org/blog/personal/80-aligning-an-ssd-on-linux 32*32] (=2^10) which results in (2^10*512=) 512 KiB alignment:<br />
<br />
# fdisk -H 32 -S 32 /dev/sdX<br />
<br />
How does the math work out? The alignment number is the largest power-of-two divisor of the cylinder boundary positions on the disk. The size in bytes of the cylinders is H*S*512 = (tracks per cylinder) * (sectors per track) * (sector size). Factorize H, S and sector size (512=2^9) into prime factors, and take all the 2s. In the first case above we have to ignore the non-power-of-two factor of 7^2=49.<br />
<br />
{{Note|In order to be compatible with MS-DOS, a partition starting on the first cylinder would skip one track, reducing its alignment to track level (4k for -S 56 and 16k for -S 32). The easiest way to maximally align the first partition is to start it at cylinder 2 rather than the default of cylinder 1 as shown in the example below.}}<br />
<br />
===== Fdisk Usage Summary =====<br />
*Start fdisk using the correct values for H and S specific to your SSD as described above.<br />
*If the SSD is brand new, create a new empty DOS partition table with the 'o' command.<br />
*Create a new partition with the 'n' command (primary type/1st partition).<br />
*Start on sector 2 rather than on sector 1 to ensure MS-DOS compatibility if this is required; accept the default value if not.<br />
*Use the +xG format to extend the partition x gigabytes.<br />
*Change the partition's system id from the default type of Linux (type 83) to the desired type via the 't' command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, etc. Note that a complete listing of all valid partition types is available via the 'l' command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the 'w' command.<br />
<br />
When finished, users may format their newly created partitions with the 'mkfs.x /dev/sdXN' where x is the filesystem, X is the drive letter, and N is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{Filename|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the mkfs command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
====== Detailed Usage Example ======<br />
{{Note|The following section is meant to be illustrative of the process of partitioning an Intel X25-M SSD with a single 12 Gig, Linux partition. It is in no way the definitive method for doing so, nor are the switches used to start fdisk in this specific example necessarily the correct values for other brands/models of SSDs!}}<br />
<br />
<pre># fdisk -H 32 -S 32 /dev/sdb<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
<br />
Command (m for help): o<br />
Building a new DOS disklabel with disk identifier 0x8cb3d286.<br />
Changes will remain in memory only, until you decide to write them.<br />
After that, of course, the previous content won't be recoverable.<br />
<br />
The number of cylinders for this disk is set to 15711.<br />
There is nothing wrong with that, but this is larger than 1024,<br />
and could in certain setups cause problems with:<br />
1) software that runs at boot time (e.g., old versions of LILO)<br />
2) booting and partitioning software from other OSs<br />
(e.g., DOS FDISK, OS/2 FDISK)<br />
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)<br />
<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-15711, default 1): 2<br />
Last cylinder, +cylinders or +size{K,M,G} (2-15711, default 15711): +12G<br />
<br />
Command (m for help): w<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.</pre><br />
<br />
The rest of the SSD was partitioned in a like fashion giving two partitions totally. Here is the output of an fdisk list command:<br />
<pre># fdisk -l /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders<br />
Units = cylinders of 1024 * 512 = 524288 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 2 24578 12583424 83 Linux<br />
/dev/sdb2 24579 152638 65566720 83 Linux</pre><br />
<br />
And a fdisk -lu command:<br />
<pre># fdisk -lu /dev/sdb<br />
<br />
Disk /dev/sdb: 80.0 GB, 80026361856 bytes<br />
32 heads, 32 sectors/track, 152638 cylinders, total 156301488 sectors<br />
Units = sectors of 1 * 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x76b978dc<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sdb1 1024 25167871 12583424 83 Linux<br />
/dev/sdb2 25167872 156301311 65566720 83 Linux</pre><br />
<br />
{{Warning| Pay attention to this last sanity check step. If the heads and sectors/track do not remain 32/32, it is either due to a bug in fdisk, or for an unknown reason, the partitions are not aligned! See the [[http://wiki.archlinux.org/index.php/SSD_Memory_Cell_Clearing#Post_Process_Observation using cfdisk/post process observation]] wiki page for a work around.}}<br />
<br />
====== Special Considerations for Logical Partitions ======<br />
<br />
---Place holder for content. <br />
<br />
====== Special Considerations for RAID0 Setups with Multiple SSDs ======<br />
<br />
---Place holder for content.<br />
<br />
===Encrypted partition===<br />
<br />
When using cryptsetup, define a sufficient payload ([http://www.spinics.net/lists/dm-crypt/msg02421.html see here]):<br />
cryptsetup luksFormat --align-payload=8192 ...<br />
But remember that DISCARD/TRIM feature is NOT SUPPORTED by device-mapper (but they're working on it, [http://news.gmane.org/find-root.php?group=gmane.linux.kernel.device-mapper.dm-crypt&article=4075 see here])<br />
<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{filename|/etc/fstab}} entries for SSD partitions.<br />
<br />
*'''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
*'''discard''' - The discard flag will enable the benefits of the TRIM command so long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,noatime,discard 0 1<br />
<br />
{{Note|You can also set the discard flag with tune2fs: tune2fs -o discard /dev/sda1.}}<br />
{{Accuracy}}<br />
{{Warning|It is critically important that users switch the controller driving the SSD to AHCI mode (not IDE mode) to ensure that the kernel is able to use the TRIM command.}} <br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the discard flag. Data loss can occur otherwise!}}<br />
{{Warning|Using an OCZ Vertex II SSD (supports TRIM) and kernel 2.6.37.4 on Arch, some people experienced trouble with the '''discard''' option: all changes made to the filesystem would disappear after a reboot! According to [http://www.mjmwired.net/kernel/Documentation/filesystems/ext4.txt#356 this], '''discard''' is disabled by default because it not stable enough.}}<br />
<br />
====Special considerations for Mac computers====<br />
<br />
By default, Apple's firmware switches SATA drives into IDE mode (not AHCI mode) when booting any OS besides Mac OS. It is easy to switch back to AHCI if you are using [[GRUB2]] with an Intel SATA controller.<br />
<br />
First determine the PCI identifier of your SATA controller. Run the command<br />
# lspci -nn<br />
and find the line that says "SATA AHCI Controller". The PCI identifier is in square brackets and should look like 8086:27c4 (but the last digits may be different).<br />
<br />
Now edit /boot/grub/grub.cfg and add the line <br />
# setpci -d 8086:27c4 90.b=40<br />
right above the "set root" line of each OS you want to enable AHCI for. Be sure to substitute the appropriate PCI identifier.<br />
<br />
(credit: http://darkfader.blogspot.com/2010/04/windows-on-intel-mac-and-ahci-mode.html)<br />
<br />
=== I/O Scheduler ===<br />
<br />
{{Note|This should not be necessary since the cfq scheduler checks if the drive is non-rotational and then behaves correctly for an SSD.}}<br />
<br />
Consider switching from the default scheduler, which under Arch is cfq (completely fair queuing), to the noop or deadline scheduler for an SSD. Using the noop scheduler, for example, simply processes requests in the order they are received, without giving any consideration to where the data physically resides on the disk. This option is thought to be advantageous for SSDs since seek times are identical for all sectors on the SSD.<br />
<br />
However, for some SSDs, particularly earlier, JMicron-based ones, you may experience better performance sticking with the default scheduler (see [http://www.alphatek.info/2009/02/02/io-scheduler-and-ssd-part-2/ here] for one such benchmark); on these, while seek times are similar for all sectors, random access throughput is bad enough to offset any advantage. If your SSD was manufactured within the last year or so, or is made by Intel, this probably doesn't apply to you.<br />
<br />
For more on schedulers, see [http://www.linux-mag.com/id/7564/1 this] Linux Magazine article (needs registration).<br />
<br />
About the default scheduler for ssd drives: https://bugs.archlinux.org/task/22605<br />
<br />
The cfq scheduler is enabled by default on Arch. Verify this by viewing the contents /sys/block/sda/queue/scheduler:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
There are several ways to change the scheduler.<br />
<br />
{{Note|Only switch the scheduler to noop or deadline for SSDs. Keeping the cfq scheduler for all other physical HDDs is ''highly'' recommended.}}<br />
<br />
===== Using the sys virtual filesystem =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
Add the following line in {{Filename|/etc/rc.local}}:<br />
echo noop > /sys/block/sdX/queue/scheduler<br />
Where X is the letter for the SSD device.<br />
<br />
===== Kernel parameter =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the elevator kernel parameter:<br />
elevator=noop<br />
<br />
For example, with GRUB, in {{Filename|/boot/grub/menu.lst}}:<br />
kernel /vmlinuz26 root=/dev/sda3 ro elevator=noop<br />
or with GRUB2, in {{Filename|/etc/default/grub}}: (remember to run update-grub afterwards)<br />
GRUB_CMDLINE_LINUX="elevator=noop"<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swapiness" of the system thus avoiding writes to swap.<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{Filename|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article.<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time he/she installed the device thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use "iotop -oPa" and sort by disk writes to see how much your programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
Consider relocating the /var partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. Many users elect to keep only /, and /home on the SSD (/boot is okay too) locating /var and /tmp on a physical HDD. <br />
<br />
<pre># SSD<br />
/<br />
/home<br />
<br />
# HDD<br />
/boot<br />
/var<br />
/media/data (and other extra partitions, etc.)</pre><br />
<br />
If the SSD is the only storage device on the system (i.e. no HDDs), consider allocating a separate partition for /var to allow for better crash recovery for example in the event of a broken program wasting all the space on / or if some run away log file maxes out the space, etc.<br />
<br />
Another intelligent option is to locate /tmp is into RAM provided the system has enough to spare. See the next section for more on this procedure.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the '''noatime''' flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section below for more.<br />
<br />
=== Locate /tmp in RAM ===<br />
For systems with >=2 gigs of memory, locating /tmp in the RAM is desirable and easily achieved by first clearing the physical /tmp partition and then mounting it to tmpfs (RAM) in the {{Filename|/etc/fstab}}. The following line gives an example:<br />
<br />
none /tmp tmpfs nodev,nosuid,noatime,size=1000M,mode=1777 0 0<br />
<br />
=== Locate Browser Profiles in RAM ===<br />
One can easily mount browser profile(s) such as firefox, chromium, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. For more on this procedure, see the [http://wiki.archlinux.org/index.php/Speed-up_Firefox_using_tmpfs Speed-up Firefox Using tmpfs] article. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
=== Compiling in /dev/shm ===<br />
Intentionally compiling in /dev/shm is a great idea to minimize this problem. For systems with >4 Gigs of memory, the shm line in {{Filename|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the size flag.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
shm /dev/shm tmpfs nodev,nosuid,size=6G 0 0<br />
<br />
=== Disabling Journaling on the Filesystem? ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in /dev/shm as recommended in the [http://wiki.archlinux.org/index.php/Solid_State_Drives#Compiling_in_.2Fdev.2Fshm preceding section] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
Many options exist for file systems including ext2, ext3, ext4, btrfs, etc.<br />
<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. It should be noted that at the time this article was originally written (27-June-2010), a stable version of btrfs did not exist. See [http://www.madeo.co.uk/?p=346 this] blog entry for more on btrfs. Be sure to read the [https://btrfs.wiki.kernel.org/index.php/Main_Page btrfs wiki] as well.<br />
<br />
{{Warning|At the time this entry was written (21-Nov-2010) there is NO fsck utility to fix/diagnose errors on btrfs partitions. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably in the event of a crash or power loss on disks that don't handle flush requests correctly.}}<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filsesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detects the disk nature and you have to explicitly enable the TRIM command support using the '''discard''' mounting option in your [[fstab]] (or with tune2fs -o discard /dev/sdaX).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/btrfs.txt;h=64087c34327fe0ba11e790e0a41224b8e7c1d30c;hb=HEAD official in kernel tree documentation] for further information on ext4.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking your SSD or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== OCZ ===<br />
OCZ has a command line utility available for linux (i686 and x86_64) on their forum [http://www.ocztechnologyforum.com/forum/showthread.php?82289-1st-Public-beta-test-of-OCZ-Sandforce-Linux-based-firmware-upddate-tool here].</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=ArchWiki:Translation_Team_(Italiano)&diff=139342ArchWiki:Translation Team (Italiano)2011-05-02T19:48:21Z<p>Lorenzog: /* Bando di traduzione */</p>
<hr />
<div>[[Category:Italiano]]<br />
{{i18n|ArchWiki Translation Team}}<br />
<br />
{{Expansion}}<br />
<br />
=Pagina di Prenotazione Traduzioni ArchWiki Italia=<br />
<br />
Questa pagina è riservata al [http://www.archlinux.it/forum/viewtopic.php?id=8483 Team Italiano Traduzioni Arch Wiki], supportato e gestito dalla comunità del forum di [http://www.archlinux.it/ Arch Linux Italia]. Lo scopo di questo progetto è quello di allineare gli articoli italiani con quelli inglesi, tenerli costantemente aggiornati, e nel caso ve ne fosse bisogno, aiutare lo sviluppo della documentazione inglese. Gli articoli vengono scelti in base alla loro importanza ed utilità, non ultimo viene considerata la ramificazione di articoli correlati ai medesimi. Questa pagina è suddivisa in due parti principali.<br />
#Bando di Traduzioni (ove si segnalano e si tiene conto delle traduzioni in corso)<br />
#Revisioni (ove gli articoli già tradotti dal nostro team vengono messi sotto osservazione)<br />
<br />
In ogni paragrafo viene fornita una spiegazione esaustiva, quindi si consiglia di leggere attentamente quanto segue. Inoltre si dia una lettura a [http://www.archlinux.it/forum/viewtopic.php?id=8483 questa discussione] dove vengono fornite informazioni dettagliate e linee guida da seguire e a cui rivolgersi per partecipare.<br />
Per prenotare una traduzione, modificare questa pagina, aggiungendo '''alla riga subito sotto il paragrafo/articolo scelto''' il proprio nome, ed '''alle righe successive''' quanto richiesto dalla tabella.<br />
Grazie della collaborazione.<br />
<br />
==Bando di traduzione==<br />
<br />
Questa è la sezione principale del progetto dove vengono immesse le nuove pagine da tradurre, ed è presente una tabella ove si prenotano i vari paragrafi. Per prenotarsi, basta editare questa sezione ed aggiungere il proprio nome utente sotto il nome del paragrafo scelto, e nella riga ancora sottostante descrivere l'andamento della traduzione che può essere: "'''In Corso'''" (quando iniziate la traduzione), "'''Verifica'''" (nel caso in cui l'abbiate terminata ma vogliate ancora dare un ulteriore sguardo, o non siete sicuri del vostro lavoro), "'''Completa'''" ( da utilizzare a lavoro ultimato). L'apposizione dello stato "''Completo''" fa sì che il responsabile di turno sposti il wiki tradotto completamente nella sezione [[Traduzioni#Revisioni|Revisioni]], '''non sta al traduttore prendersi carico di questo onere'''. A coloro che si prenotano per tradurre il primo paragrafo spetta anche il compito di traduzione dell'eventuale testo antecedente e del sommario.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! scope="col" width="40%" | Pagina<br />
! scope="col" width="40%" | Paragrafo<br />
! scope="col" width="10%" | Traduttore<br />
! scope="col" width="10%" | Stato<br />
|-<br />
| [[Conky (Italiano)]]<br />
|<br />
| Wolfanger<br />
| In Corso<br />
|-<br />
| [[Common Applications (Italiano)]]<br />
| Pagina allineata alla versione inglese (29/12/2010)<br />
| Garrett<br />
| In Corso<br />
|-<br />
| [[Lightweight Applications (Italiano)]]<br />
| Pagina allineata alla versione inglese (29/12/2010)<br />
| Artaserse<br />
| In Corso<br />
|-<br />
| [[Plasma (Italiano)]]<br />
| Pagina allineata il 27/12/2010<br />
| Trapanator<br />
| In corso<br />
|-<br />
| [[Eclipse plugin package guidelines (Italiano)]]<br />
| Guida correlata ad Arch Packaging Standards (allineata 23/12/2010)<br />
| Debbio<br />
| In corso<br />
|-<br />
| [[Lisp Package Guidelines (Italiano)]]<br />
| Guida correlata ad Arch Packaging Standards (allineata 23/12/2010)<br />
| lorenzog<br />
| Completa<br />
|-<br />
| [[Uniform Look for QT and GTK Applications (Italiano)]]<br />
| <br />
| ant84<br />
| In Corso<br />
|-<br />
| [[Wicd (Italiano)]]<br />
| Pagina allineata alla versione inglese (22/04/2011) <br />
| Maveloth<br />
| completata<br />
|}<br />
<br />
===Pagine in Sospeso===<br />
<br />
In questa sotto-sezione trovano posto quelle pagine che pur se prese in considerazione, sono state taggate in vario modo, magari come "merging", "stub" etc... e in teoria si attende che la versione inglese subisca una revisione definitiva. Nella tabella seguente le pagine segnalate come da "'''Allineare'''" indicano quelle pagine completamente da revisionare , e da allineare alla versione inglese. Vengono spostate in questa tabella anche pagine in sospeso per varia natura, sono comunque articoli che in futuro verranno allineati e spostati nel [[Traduzioni#Bando di traduzione|Bando di traduzione]] quando disponibili.<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="35%" | Motivazione<br />
! scope="col" width="30%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[IceWM]]<br />
| Pagina segnalata come '''Stub'''<br />
|<br />
|-align="center"<br />
| [[WindowLab]]<br />
| Pagina segnalata come '''Stub'''<br />
|<br />
|-align="center"<br />
| [[Kernel Module Package Guidelines (Italiano)]]<br />
| Pagina segnalata come '''Stub'''<br />
| 2010-12-30<br />
|-align="center"<br />
| [[KDEmod (Italiano)]]<br />
| pagina in attesa di '''rimozione'''<br />
| 2011-01-02<br />
|-align="center"<br />
| [[Python Package Guidelines (Italiano)]]<br />
| Pagina segnalata come '''Stub'''<br />
| 2010-12-30<br />
|-align="center"<br />
| [[Eclipse]]<br />
| Pagina segnalata come '''Stub'''<br />
|<br />
|-align="center"<br />
| [[Ruby Gem Package Guidelines (Italiano)]]<br />
| Pagina segnalata come '''Stub'''<br />
| 2011-01-10<br />
|-<br />
|}<br />
<br />
=Revisioni=<br />
In questa sezione verranno messi i vari articoli del wiki già tradotti precedentemente dal nostro staff, verrà inserita la data di ultima revisione e eventualmente il ''nome utente'' e lo ''stato'' di revisione in caso si stia procedendo al riallineamento della pagina rispetto al wiki inglese. '''Attenzione le date sono in stile anglosassone ovvero : yyyy-mm-gg (ES. 2011-01-30)'''. Le revisioni degli articoli non seguono una procedura temporale specifica, ognuno è libero di controllare lo stato di allineamento di un wiki già trattato in precedenza, oppure può procedere all' '''adozione''' del medesimo.<br />
<br />
== Adottare un WIKI==<br />
È possibile '''Adottare''' un wiki a vostra scelta, l'adozione di un wiki comporta la piena responsabilità della revisione e allineamento continuo della pagina che si prende in custodia. Per procedere all'adozione si consiglia di:<br />
<br />
* Controllare le [https://wiki.archlinux.org/index.php/Special:Preferences preferenze del vostro profilo] sul wiki e selezionare l'opzione (disattivata di default) per essere avvisati via e-mail dei cambiamenti nelle pagine da voi messe sotto osservazione. In particolare devono essere spuntate tutte le seguenti opzioni : <br />
::Segnalami via e-mail le modifiche alle pagine osservate <br\> Segnalami via e-mail le modifiche alla mia pagina di discussione <br\> Segnalami via e-mail anche le modifiche minori<br />
*Aggiungere tra i propri [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] la pagina che si vuole adottare, accessibile nel menu del proprio profilo, è possibile aggiungere le pagine cliccando su [https://wiki.archlinux.org/index.php/Special:Watchlist/raw Modifica la lista in formato testo] (fate attenzione all'ortografia e in caso di più pagine aggiungetele una sotto l'altra)<br />
<br />
Dalla pagina [https://wiki.archlinux.org/index.php/Special:Watchlist Osservati Speciali] e possibile seguire tutte le variazioni delle pagine da noi adottate in un unico resoconto. Se avete seguito attentamente la procedura indicata, verrete contattati via email nel caso di cambiamenti anche minori delle pagine adottate.<br />
<br />
{{nota|Nella email che vi viene mandata come avviso, vi sarà anche un link diretto alla Diff della cronologia dell'articolo preso in esame (è il secondo link in ordine). '''Fate attenzione''', non sempre le modifiche mostrate sono complete, soprattutto nel caso di molte modifiche ravvicinate. É preferibile, una volta ricevuto l'avviso di revisione, procedere con un Diff personalizzato, impostando una data antecedente all'ultima revisione nella scheda ''cronologia''.}}<br />
<br />
A distanza di un certo periodo di tempo un ''Supervisore'' controllerà lo stato di aggiornamento dei wiki adottati, e nel caso si riscontrassero delle inadempienze, verrà segnalato ai rispettivi utenti di procedere al riallineamento. <br />
Le categorie qui di seguito, non rispettano la reale classificazione del wiki, ma seguono un nostro principio di adozione e classificazione.<br />
<br />
====Guide Fondamentali====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="15%" | Ultima revisione<br />
! scope="col" class="unsortable" width="50%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[Beginners' Guide (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
|-align="center"<br />
| [[GRUB (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata''' <br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture (Italiano)]]<br />
| 2011-02-23<br />
| 4javier - '''Adottato'''<br />
|-align="center"<br />
| [[Xorg (Italiano)]] <br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Pacman (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata''' <br />
|-align="center"<br />
| [[The Arch Way (Italiano)]]<br />
| 2011-04-21<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Arch Linux (Italiano)]]<br />
| 2011-04-21<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Main Page (Italiano)]]<br />
| 2011-04-12<br />
| kynikos - '''Adottato'''<br />
|}<br />
<br />
====Pagine Wiki correlate alla Guida per Principianti====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="15%" | Ultima revisione<br />
! scope="col" class="unsortable" width="50%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[Arch Packaging Standards (Italiano)]]<br />
| 2011-02-20<br />
| Toketin - '''Adottato'''<br />
|-align="center"<br />
| [[VCS PKGBUILD Guidelines (Italiano)]]<br />
| 2011-03-17<br />
| 4javier - '''Adottato'''<br />
|-align="center"<br />
| [[Gnome package guidelines (Italiano)]]<br />
| 2011-03-17<br />
| 4javier - '''Adottato'''<br />
|-align="center"<br />
| [[Java Package Guidelines (Italiano)]]<br />
| 2011-02-06<br />
|<br />
|-align="center"<br />
| [[Perl Package Guidelines (Italiano)]]<br />
| 2011-03-25<br />
| Hilinus - '''Adottato'''<br />
|-align="center"<br />
| [[OCaml Package Guidelines (Italiano)]]<br />
| 2011-04-12<br />
| kynikos - '''Adottato'''<br />
|-align="center"<br />
| [[Arch wine PKGBUILD guidelines (Italiano)]]<br />
| 2001-03-26<br />
| maveloth - '''Adottato'''<br />
|-align="center"<br />
| [[Haskell package guidelines (Italiano)]]<br />
| 2011-04-03<br />
| Hilinus - '''Adottato'''<br />
|}<br />
<br />
====Driver Video====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="15%" | Ultima revisione<br />
! scope="col" class="unsortable" width="50%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[ATI Catalyst (Italiano)]]<br />
| 2011-02-19<br />
| 4javier -'''Adottato''' Versione inglese segnalata come "mal scritta"<br />
|-align="center"<br />
| [[ATI (Italiano)]]<br />
| 2011-01-07<br />
| 4javier -'''Adottato''' Alcune sezioni rimaste ''out of date'' di cui una parte non è tradotta - attendo che il wiki inglese sia riaggiornato.<br />
|-align="center"<br />
| [[NVIDIA (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
|-align="center"<br />
| [[Intel (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
|-align="center"<br />
| [[Nouveau (Italiano)]]<br />
| 2010-12-13<br />
| Berseker - '''Adottato'''<br />
|-<br />
|}<br />
<br />
====Ambienti Desktop====<br />
<br />
La colonna "Cedibile" è in prova<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="15%" | Ultima revisione<br />
! scope="col" width="45%" | Nome e Note Revisore<br />
! scope="col" width="5%" | Cedibile<br />
|-align="center"<br />
| [[Window Manager (Italiano)]]<br />
| 2011-04-19<br />
| Debbio - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Gnome 2.30 Changes (Italiano)]] <br />
| 2011-03-20<br />
| icetux - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Gnome 2.28 Changes (Italiano)]]<br />
| 2011-03-20<br />
| icetux - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[GNOME (Italiano)]]<br />
| 2011-04-26<br />
| icetux - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Gnome Tips (Italiano)]]<br />
| 2011-03-22<br />
| Debbio - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Enlightenment (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Compiz (Italiano)]]<br />
| 2010-12-19<br />
| Berseker - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Compiz Troubleshooting (Italiano)]]<br />
| 2011-04-19<br />
| Debbio - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[KDE (Italiano)]]<br />
| 2011-04-19<br />
| Debbio - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Fluxbox (Italiano)]]<br />
| 2011-03-24<br />
| Debbio - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Fluxbox Style Guide (Italiano)]]<br />
| 2010-12-27<br />
| Debbio - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[LXDE (Italiano)]]<br />
| 2011-01-06<br />
| xaber - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Awesome3 (Italiano)]]<br />
| 2011-01-06<br />
| Delcaran - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Evilwm (Italiano)]]<br />
| 2010-12-01<br />
| Debbio - '''Adottato'''<br />
| <br />
|-align="center"<br />
| [[Cwm (Italiano)]]<br />
| 2010-11-30<br />
| Debbio - '''Adottato'''<br />
| <br />
|-align="center"<br />
| [[JWM (Italiano)]]<br />
| 2011-02-12<br />
| Debbio - '''Adottato'''<br />
| <br />
|-align="center"<br />
| [[Pawm (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
| X<br />
|-align="center"<br />
| [[PekWM (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
| X<br />
|-align="center"<br />
| [[Twm (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
| X<br />
|-align="center"<br />
| [[Window Maker (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
| X<br />
|-align="center"<br />
| [[Sugar (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
| X<br />
|-align="center"<br />
| [[Openbox (Italiano)]]<br />
| 2010-12-03<br />
| 4javier - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[FVWM (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
| X<br />
|-align="center"<br />
| [[E17 (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Desktop Environment (Italiano)]]<br />
| 2011-05-01<br />
| Veleno77 - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[Xfce (Italiano)]]<br />
| 2011-04-19<br />
| Debbio - '''Adottato'''<br />
|<br />
|-align="center"<br />
| [[GNOME 3 (Italiano)]]<br />
| 2011-04-15<br />
| 4javier - '''Adottato'''<br />
|<br />
|}<br />
<br />
====File====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="15%" | Ultima revisione<br />
! scope="col" class="unsortable" width="50%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[Resolv.conf (Italiano)]]<br />
| 2010-11-14<br />
| Maveloth - '''Adottata'''<br />
|-align="center"<br />
| [[Fstab (Italiano)]]<br />
| 2011-04-28<br />
| Maveloth - '''Adottata'''<br />
|-align="center"<br />
| [[Mkinitcpio (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Xinitrc (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Rc.conf (Italiano)]]<br />
| 2010-12-10<br />
| 4javier - '''Adottata'''<br />
|- <br />
|}<br />
<br />
====Guide di Sistema di Arch Linux====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="15%" | Ultima revisione<br />
! scope="col" class="unsortable" width="50%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[Arch User Repository (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Makepkg (Italiano)]]<br />
| 2011-04-27<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Creating Packages (Italiano)]]<br />
| 2010-12-29<br />
| Ossk - '''Adottato'''<br />
|-align="center"<br />
| [[Official Repositories (Italiano)]]<br />
| 2011-03-20<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Arch Build System (Italiano)]]<br />
| 2010-12-10<br />
| 4javier - '''Adottato'''<br />
|-align="center"<br />
| [[Sudo (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata''' <br />
|-align="center"<br />
| [[PKGBUILD (Italiano)]]<br />
| 2010-12-11<br />
| 4javier - '''Adottato''' <br />
|-align="center"<br />
| [[Namcap (Italiano)]]<br />
| 2011-03-18<br />
| thewall - '''Adottato''' <br />
|-align="center"<br />
| [[Arch Boot Process (Italiano)]]<br />
| 2011-03-29<br />
| Maveloth - '''Adottata''' <br />
|-align="center"<br />
| [[Downgrading Packages (Italiano)]]<br />
| 2011-03-20<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Mirrors (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata''' <br />
|-align="center"<br />
| [[Nano (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Install from a USB flash drive (Italiano)]]<br />
| 2011-04-19<br />
| Debbio - '''Adottata'''<br />
|-<br />
|-align="center"<br />
| [[Netcfg (Italiano)]]<br />
| 2011-03-24<br />
| Toketin - '''Adottata'''<br />
|-<br />
|-align="center"<br />
| [[Clyde (Italiano)]]<br />
| 2010-12-11<br />
| Berseker - '''Adottato'''<br />
|-<br />
|-align="center"<br />
| [[Install from SSH (Italiano)]]<br />
| 2011-01-07<br />
| Stele - '''Adottato'''<br />
|-<br />
|-align="center"<br />
| [[Install from Existing Linux (Italiano)]]<br />
| 2011-01-07<br />
| Stele - '''Adottato'''<br />
|-align="center"<br />
| [[Users and Groups (Italiano)]]<br />
| 2011-03-16<br />
| Maveloth - '''Adottato'''<br />
|-align="center"<br />
| [[Start X at Boot (Italiano)]]<br />
| 2011-03-21<br />
| Hilinus - '''Adottato'''<br />
|-align="center"<br />
| [[Display Manager (Italiano)]]<br />
| 2011-03-21<br />
| Hilinus - '''Adottato'''<br />
|-align="center"<br />
| [[Burg (Italiano)]]<br />
| 2011-03-22<br />
|<br />
|}<br />
<br />
====Varie====<br />
<br />
{| class="wikitable sortable collapsible" border="1"<br />
|-<br />
! scope="col" width="35%" | Pagina<br />
! scope="col" width="15%" | Ultima revisione<br />
! scope="col" class="unsortable" width="50%" | Nome e Note Revisore<br />
|-align="center"<br />
| [[Using SSH Keys (Italiano)]]<br />
| 2011-03-24<br />
| Maveloth - '''Adottata'''<br />
|-align="center"<br />
| [[SSH (Italiano)]]<br />
| 2011-04-27<br />
| Maveloth - '''Adottata'''<br />
|-align="center"<br />
| [[Daemon (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Persistent block device naming (Italiano)]]<br />
| 2010-12-14<br />
| Maveloth - '''Adottata''' <br />
|-align="center"<br />
| [[Udev (Italiano)]]<br />
| 2010-04-27<br />
| Maveloth - '''Adottata'''<br />
|-align="center"<br />
| [[Speed Up udev (Italiano)]]<br />
| 2011-01-20<br />
| Maveloth - '''Adottata'''<br />
|-align="center"<br />
| [[Execute on usb insert (Italiano)]]<br />
| 2011-01-20<br />
| Maveloth - '''Adottata'''<br />
|-align="center"<br />
| [[Ext3 Filesystem Tips (Italiano)]]<br />
| 2011-02-06<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Ext4 (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Font Configuration (Italiano)]]<br />
| 2011-04-08<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Filesystem Hierarchy Standard (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[Bluetooth (Italiano)]]<br />
| 2011-04-09<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Touchpad Synaptics (Italiano)]]<br />
| 2011-04-19<br />
| Debbio - '''Adottato''' <br />
|-align="center"<br />
| [[Network Time Protocol daemon (Italiano)]]<br />
| 2011-03-20<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[OpenNTPD (Italiano)]]<br />
| 2011-02-20<br />
| Toketin - '''Adottato'''<br />
|-align="center"<br />
| [[Configuring Network (Italiano)]]<br />
| 2011-03-24<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Wireless Setup (Italiano)]] <br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[WPA Supplicant (Italiano)]]<br />
| 2010-12-25<br />
| Ossk - '''Adottato'''<br />
|-align="center"<br />
| [[Printing with CUPS (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[NetworkManager (Italiano)]]<br />
| 2011-05-01<br />
| Morbin - '''Adottata'''<br />
|-align="center"<br />
| [[KDM (Italiano)]]<br />
| 2011-03-20<br />
| icetux - '''Adottato'''<br />
|-align="center"<br />
| [[Mutt (Italiano)]]<br />
| 2011-02-06<br />
|<br />
|-align="center"<br />
| [[Mpd (Italiano)]]<br />
| 2011-01-08<br />
| Delcaran - '''Adottato'''<br />
|-align="center"<br />
| [[Java (Italiano)]]<br />
| 2011-02-28<br />
| thewall - '''Adottato'''<br />
|-align="center"<br />
| [[Synergy (Italiano)]]<br />
| 2011-04-12<br />
| Kynikos - '''Adottato''' <br />
|-align="center"<br />
| [[Connman (Italiano)]]<br />
| 2011-02-26<br />
|<br />
|-align="center"<br />
| [[OSS (Italiano)]]<br />
| 2011-02-21<br />
| asa - '''Adottato'''<br />
|-align="center"<br />
| [[Sound (Italiano)]]<br />
| 2011-02-21<br />
| asa - '''Adottato'''<br />
|-align="center"<br />
| [[Powerpill (Italiano)]]<br />
| 2011-04-12<br />
| kynikos - '''Adottato'''<br />
|-align="center"<br />
| [[Using Powerpill with AIF (Italiano)]]<br />
| 2011-04-12<br />
| kynikos - '''Adottato'''<br />
|-align="center"<br />
| [[KVM (Italiano)]]<br />
| 2011-03-11<br />
| 4javier - '''Adottato'''<br />
|-align="center"<br />
| [[Getting Involved (Italiano)]]<br />
| 2011-04-12<br />
| kynikos - '''Adottato'''<br />
|-align="center"<br />
| [[General Recommendations (Italiano)]]<br />
| 2011-03-01<br />
| asa - '''Adottato'''<br />
|-align="center"<br />
| [[Installing Arch Linux on a USB key (Italiano)]]<br />
| 2011-03-17<br />
| lorenzog - '''Adottato'''<br />
|-align="center"<br />
| [[VirtualBox (Italiano)]]<br />
| 2011-03-21<br />
| ant84 - '''Adottato'''<br />
|-align="center"<br />
| [[Samba (Italiano)]]<br />
| 2011-03-30<br />
| Maveloth - '''Adottato'''<br />
|-align="center"<br />
| [[Autofs (Italiano)]]<br />
| 2011-03-21<br />
| Maveloth - '''Adottato'''<br />
|-align="center"<br />
| [[Webmin (Italiano)]]<br />
| 2011-03-21<br />
| Maveloth - '''Adottato'''<br />
|-align="center"<br />
| [[PulseAudio (Italiano)]]<br />
| 2011-03-22<br />
| Hilinus - '''Adottato'''<br />
|-align="center"<br />
| [[Advanced Linux Sound Architecture/Example Configurations (Italiano)]]<br />
| 2011-04-03<br />
| 4javier - '''Adottato'''<br />
|}<br />
<br />
=Staff Tecnico=<br />
In questo spazio ogni utente può inserire o cancellare il proprio nome se lo desidera.<br />
<br />
* '''Responsabili del progetto'''<br />
:#Veleno77 - Supervisore<br />
:#4javier<br />
:# morbin<br />
:# debbio<br />
<br />
* '''Traduttori'''<br />
:# veleno77 <br />
:# debbio<br />
:# 4javier<br />
:# morbin<br />
:# lolloso<br />
:# Simandr<br />
:# oceans11<br />
:# toketin<br />
:# Berseker<br />
:# Gilmo<br />
:# Trapanator<br />
:# Pappe<br />
:# Linux@to<br />
:# Ossk<br />
:# Gianfrix<br />
:# Maveloth<br />
:# icetux<br />
:# Ahel<br />
:# Wolfanger<br />
:# Asa<br />
:# TheKaspa<br />
:# thewall<br />
:# lorenzog<br />
:# Kynikos<br />
:# Hilinus<br />
:# ant84<br />
<br />
=Ulteriori informazioni e supporto=<br />
Per informazioni e delucidazioni sul progetto di traduzione e mantenimento wiki italiano, consultare il [http://www.archlinux.it/forum/viewtopic.php?id=8483 forum italiano]</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139341Lisp package guidelines (Italiano)2011-05-02T19:45:24Z<p>Lorenzog: </p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre''' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Packaging per versioni specifiche di Lisp ==<br />
<br />
Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere indipendenti dall piattaforma per quanto il pacchetto lo permetta.<br />
Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.<br />
<br />
Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD '''common-lisp'''. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di ''sbcl'' e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute. <br />
<br />
C'è anche da notare che se ASDF è necessario per installare/compilare/caricare il pacchetto le cose possono potenzialmente diventare più complicate a causa delle dipendenze, dal momento che SBCL viene fornito con asdf, clisp no ma c'è un pacchetto in AUR, e CMUCL potrebbe o meno fornirlo. (Purtroppo l'autore di questa pagina non conosce praticamente niente di CMUCL; mi dispiace).<br />
<br />
Le persone che stanno attualmente mantenendo dei pacchetti lisp relativi ad una particolare implementazione di lisp ma che non necessitano di una particolare implementazione per funzionare potrebbero considerare di fare almeno una delle seguenti cose: <br />
<br />
* Modificare i propri PKGBUILD(s) per essere indipendenti dalla piattaforma, assicurandosi che qualcun'altro che non stia già mantenendo lo stesso pacchetto per un'implementazione diversa.<br />
<br />
* Offrirsi di farsi carico o aiutare con il mantenimento di versioni dello stesso pacchetto anche per altre implementazioni di lisp e combinarle in un unico pacchetto <br />
<br />
* Offire il proprio pacchetto al maintainer di una versione dello stesso pacchetto per un'altra implementazione, in modo da permettergli di combinarle in un unico pacchetto.<br />
<br />
(Notare che joyfulgirl, l'autrice di questo documento, che attualmente mantiene le versioni per clisp di cl-ppcre e stumpwm; è disponibile sia a donare questi pacchetti ai maintainer delle versioni SBCL oppure mantenere la nuova versione indipendente dalla piattaforma da sola se i maintainer delle versione SBCL non se ne vogliono fare carico)<br />
<br />
== Cose che l'utente può fare ==<br />
<br />
* Mantenere pacchetti lisp seguendo queste linee-guida.<br />
* Aggiornare e correggere queste linee-guida<br />
* Seguire i cambiamenti di questa pagina<br />
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone<br />
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139340Lisp package guidelines (Italiano)2011-05-02T19:44:25Z<p>Lorenzog: </p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre'' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Packaging per versioni specifiche di Lisp ==<br />
<br />
Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere indipendenti dall piattaforma per quanto il pacchetto lo permetta.<br />
Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.<br />
<br />
Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD '''common-lisp'''. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di ''sbcl'' e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute. <br />
<br />
C'è anche da notare che se ASDF è necessario per installare/compilare/caricare il pacchetto le cose possono potenzialmente diventare più complicate a causa delle dipendenze, dal momento che SBCL viene fornito con asdf, clisp no ma c'è un pacchetto in AUR, e CMUCL potrebbe o meno fornirlo. (Purtroppo l'autore di questa pagina non conosce praticamente niente di CMUCL; mi dispiace).<br />
<br />
Le persone che stanno attualmente mantenendo dei pacchetti lisp relativi ad una particolare implementazione di lisp ma che non necessitano di una particolare implementazione per funzionare potrebbero considerare di fare almeno una delle seguenti cose: <br />
<br />
* Modificare i propri PKGBUILD(s) per essere indipendenti dalla piattaforma, assicurandosi che qualcun'altro che non stia già mantenendo lo stesso pacchetto per un'implementazione diversa.<br />
<br />
* Offrirsi di farsi carico o aiutare con il mantenimento di versioni dello stesso pacchetto anche per altre implementazioni di lisp e combinarle in un unico pacchetto <br />
<br />
* Offire il proprio pacchetto al maintainer di una versione dello stesso pacchetto per un'altra implementazione, in modo da permettergli di combinarle in un unico pacchetto.<br />
<br />
(Notare che joyfulgirl, l'autrice di questo documento, che attualmente mantiene le versioni per clisp di cl-ppcre e stumpwm; è disponibile sia a donare questi pacchetti ai maintainer delle versioni SBCL oppure mantenere la nuova versione indipendente dalla piattaforma da sola se i maintainer delle versione SBCL non se ne vogliono fare carico)<br />
<br />
== Cose che l'utente può fare ==<br />
<br />
* Mantenere pacchetti lisp seguendo queste linee-guida.<br />
* Aggiornare e correggere queste linee-guida<br />
* Seguire i cambiamenti di questa pagina<br />
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone<br />
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139339Lisp package guidelines (Italiano)2011-05-02T19:43:39Z<p>Lorenzog: /* Packaging per version specifiche di Lisp */</p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre'' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Packaging per versioni specifiche di Lisp ==<br />
<br />
Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere indipendenti dall piattaforma per quanto il pacchetto lo permetta.<br />
Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.<br />
<br />
Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD '''common-lisp'''. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di ''sbcl'' e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute. <br />
<br />
C'è anche da notare che se ASDF è necessario per installare/compilare/caricare il pacchetto le cose possono potenzialmente diventare più complicate a causa delle dipendenze, dal momento che SBCL viene fornito con asdf, clisp no ma c'è un pacchetto in AUR, e CMUCL potrebbe o meno fornirlo. (Purtroppo l'autore di questa pagina non conosce praticamente niente di CMUCL; mi dispiace).<br />
<br />
Le persone che stanno attualmente mantenendo dei pacchetti lisp relativi ad una particolare implementazione di lisp ma che non necessitano di una particolare implementazione per funzionare potrebbero considerare di fare almeno una delle seguenti cose: <br />
<br />
* Modificare i propri PKGBUILD(s) per essere indipendenti dalla piattaforma, assicurandosi che qualcun'altro che non stia già mantenendo lo stesso pacchetto per un'implementazione diversa.<br />
<br />
* Offrirsi di farsi carico o aiutare con il mantenimento di versioni dello stesso pacchetto anche per altre implementazioni di lisp e combinarle in un unico pacchetto <br />
<br />
* Offire il proprio pacchetto al maintainer di una versione dello stesso pacchetto per un'altra implementazione, in modo da permettergli di combinarle in un unico pacchetto.<br />
<br />
(Notare che joyfulgirl, l'autrice di questo documento, che attualmente mantiene le versioni per clisp di cl-ppcre e stumpwm; è disponibile sia a donare questi pacchetti ai maintainer delle versioni SBCL oppure mantenere la nuova versione indipendente dalla piattaforma da sola se i maintainer delle versione SBCL non se ne vogliono fare carico)<br />
<br />
== Cose che l'utente può fare ==<br />
<br />
* Mantenere pacchetti lisp seguendo queste linee-guida.<br />
* Aggiornare e correggere queste linee-guida<br />
* Seguire i cambiamenti di questa pagina<br />
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone<br />
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139338Lisp package guidelines (Italiano)2011-05-02T19:39:56Z<p>Lorenzog: /* Packaging per version specifiche di Lisp */</p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre'' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Packaging per version specifiche di Lisp ==<br />
<br />
Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere indipendenti dall piattaforma per quanto il pacchetto lo permetta.<br />
Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.<br />
<br />
Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD '''common-lisp'''. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di ''sbcl'' e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute. <br />
<br />
Also note that if ASDF is needed to install/compile/load the package,<br />
things could potentially get awkward as far as dependencies go, since<br />
SBCL comes with asdf installed, clisp does not but there is an AUR<br />
package, and CMUCL may or may not have it (the author of this doc.<br />
knows next to nothing about CMUCL; sorry).<br />
<br />
Le persone che stanno attualmente mantenendo dei pacchetti lisp relativi ad una particolare implementazione di lisp ma che non necessitano di una particolare implementazione per funzionare potrebbero considerare di fare almeno una delle seguenti cose: <br />
<br />
* Modificare i propri PKGBUILD(s) per essere indipendenti dalla piattaforma, assicurandosi che qualcun'altro che non stia già mantenendo lo stesso pacchetto per un'implementazione diversa.<br />
<br />
* Offrirsi di farsi carico o aiutare con il mantenimento di versioni dello stesso pacchetto anche per altre implementazioni di lisp e combinarle in un unico pacchetto <br />
<br />
* Offire il proprio pacchetto al maintainer di una versione dello stesso pacchetto per un'altra implementazione, in modo da permettergli di combinarle in un unico pacchetto.<br />
<br />
(Notare che joyfulgirl, l'autrice di questo documento, che attualmente mantiene le versioni per clisp di cl-ppcre e stumpwm; è disponibile sia a donare questi pacchetti ai maintainer delle versioni SBCL oppure mantenere la nuova versione indipendente dalla piattaforma da sola se i maintainer delle versione SBCL non se ne vogliono fare carico)<br />
<br />
== Cose che l'utente può fare ==<br />
<br />
* Mantenere pacchetti lisp seguendo queste linee-guida.<br />
* Aggiornare e correggere queste linee-guida<br />
* Seguire i cambiamenti di questa pagina<br />
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone<br />
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139337Lisp package guidelines (Italiano)2011-05-02T19:39:15Z<p>Lorenzog: /* Packaging specifico per Lisp */</p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre'' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Packaging per version specifiche di Lisp ==<br />
<br />
Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere cross-platform per quanto il pacchetto lo permetta.<br />
Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.<br />
<br />
Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD '''common-lisp'''. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di ''sbcl'' e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute. <br />
<br />
Also note that if ASDF is needed to install/compile/load the package,<br />
things could potentially get awkward as far as dependencies go, since<br />
SBCL comes with asdf installed, clisp does not but there is an AUR<br />
package, and CMUCL may or may not have it (the author of this doc.<br />
knows next to nothing about CMUCL; sorry).<br />
<br />
Le persone che stanno attualmente mantenendo dei pacchetti lisp relativi ad una particolare implementazione di lisp ma che non necessitano di una particolare implementazione per funzionare potrebbero considerare di fare almeno una delle seguenti cose: <br />
<br />
* Modificare i propri PKGBUILD(s) per essere indipendenti dalla piattaforma, assicurandosi che qualcun'altro che non stia già mantenendo lo stesso pacchetto per un'implementazione diversa.<br />
<br />
* Offrirsi di farsi carico o aiutare con il mantenimento di versioni dello stesso pacchetto anche per altre implementazioni di lisp e combinarle in un unico pacchetto <br />
<br />
* Offire il proprio pacchetto al maintainer di una versione dello stesso pacchetto per un'altra implementazione, in modo da permettergli di combinarle in un unico pacchetto.<br />
<br />
(Notare che joyfulgirl, l'autrice di questo documento, che attualmente mantiene le versioni per clisp di cl-ppcre e stumpwm; è disponibile sia a donare questi pacchetti ai maintainer delle versioni SBCL oppure mantenere la nuova versione indipendente dalla piattaforma da sola se i maintainer delle versione SBCL non se ne vogliono fare carico)<br />
<br />
== Cose che l'utente può fare ==<br />
<br />
* Mantenere pacchetti lisp seguendo queste linee-guida.<br />
* Aggiornare e correggere queste linee-guida<br />
* Seguire i cambiamenti di questa pagina<br />
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone<br />
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139335Lisp package guidelines (Italiano)2011-05-02T19:24:53Z<p>Lorenzog: /* Lisp-specific packaging */</p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre'' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Packaging specifico per Lisp ==<br />
<br />
Quando possibile, non creare pacchetti relativi ad una singola implementazione di lisp, cercare di essere cross-platform per quanto il pacchetto lo permetta.<br />
Se, nonostante tutto, il pacchetto è specificatamente pensato per una singola implementazione di lisp (ad esempio, gli sviluppatori non hanno ancora aggiunto il supporto per altre implementazioni, o il pacchetto è stato sviluppato per fornire una funzionalità già presente in altre implementazioni), è corretto fare il proprio pacchetto Arch specifico per una particolare implementazione di lisp.<br />
<br />
Per evitare di creare pacchetti specifici per una particolare implementazione, idealmente i pacchetti relativi a tutte le implementazioni (SBCL, cmucl, clisp) dovrebbero essere creati con il campo del PKGBUILD '''common-lisp'''. Comunque, non è il caso (e questo potrebbe creare problemi alla persone che preferiscono avere implementazioni multiple di lisp a portata di mano). Allo stesso tempo, si potrebbe (a) non rendere il proprio pacchetto dipendente da nessun lisp e includere nel package.install un messaggio che richieda l'installazione di lisp (non ottimale) opppure (b) seguire l'esempio del PKGBUILD di ''sbcl'' e includere un controllo condizionale per capire quale lisp è necessario (che è una soluzione complessa e, ancora, non ottimale). Altre idee sono le benvenute. <br />
<br />
<br />
Also note that if ASDF is needed to install/compile/load the package,<br />
things could potentially get awkward as far as dependencies go, since<br />
SBCL comes with asdf installed, clisp does not but there is an AUR<br />
package, and CMUCL may or may not have it (the author of this doc.<br />
knows next to nothing about CMUCL; sorry).<br />
<br />
People currently maintaining lisp-specific packages that don't need to<br />
be lisp-specific should consider doing at least one of the following:<br />
<br />
* Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.<br />
<br />
* Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.<br />
<br />
* Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.<br />
<br />
(Note that joyfulgirl, the author of this doc., currently maintains<br />
clisp versions of cl-ppcre and of stumpwm; she is open to either<br />
giving up the packages to the maintainers of the SBCL versions or to<br />
maintain the new, cross-platform versions herself if the SBCL-version<br />
maintainers don't want to).<br />
<br />
== Cose che l'utente può fare ==<br />
<br />
* Mantenere pacchetti lisp seguendo queste linee-guida.<br />
* Aggiornare e correggere queste linee-guida<br />
* Seguire i cambiamenti di questa pagina<br />
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone<br />
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139334Lisp package guidelines (Italiano)2011-05-02T19:09:27Z<p>Lorenzog: /* Things you, the reader, can do */</p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre'' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Lisp-specific packaging ==<br />
<br />
When possible, do not make packages specific to a single lisp<br />
implementation; try to be as cross-platform as the package itself will<br />
allow. If, however, the package is specifically designed for a single<br />
lisp implementation (i.e., the developers haven't gotten around to<br />
adding support for others yet, or the package's purpose is<br />
specifically to provide a capability that is built in to another lisp<br />
implementation), it is appropriate to make your Arch package<br />
lisp-specific.<br />
<br />
To avoid making packages implementation-specific, ideally all<br />
implementation packages (SBCL, cmucl, clisp) would be built with the<br />
PKGBUILD field '''common-lisp'''. However, that's not the case (and<br />
that would likely cause problems for people who prefer to have<br />
multiple lisps at their fingertips). In the meantime, you could (a)<br />
not make your package depend on *any* lisp and include a statement in<br />
the package.install file telling folks to make sure they have a lisp<br />
installed (not ideal), or (b) Take direction from the ''sbcl''<br />
PKGBUILD and include a conditional statement to figure out which lisp<br />
is needed (which is hackish and, again, far from ideal). Other ideas<br />
are welcome.<br />
<br />
Also note that if ASDF is needed to install/compile/load the package,<br />
things could potentially get awkward as far as dependencies go, since<br />
SBCL comes with asdf installed, clisp does not but there is an AUR<br />
package, and CMUCL may or may not have it (the author of this doc.<br />
knows next to nothing about CMUCL; sorry).<br />
<br />
People currently maintaining lisp-specific packages that don't need to<br />
be lisp-specific should consider doing at least one of the following:<br />
<br />
* Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.<br />
<br />
* Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.<br />
<br />
* Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.<br />
<br />
(Note that joyfulgirl, the author of this doc., currently maintains<br />
clisp versions of cl-ppcre and of stumpwm; she is open to either<br />
giving up the packages to the maintainers of the SBCL versions or to<br />
maintain the new, cross-platform versions herself if the SBCL-version<br />
maintainers don't want to).<br />
<br />
== Cose che l'utente può fare ==<br />
<br />
* Mantenere pacchetti lisp seguendo queste linee-guida.<br />
* Aggiornare e correggere queste linee-guida<br />
* Seguire i cambiamenti di questa pagina<br />
* Fornire (educatamente) consigli, pareri e suggerimenti sia su questo documento che sul lavoro delle persone<br />
* Tradurre questa pagina e futuri aggiornamenti a questa pagina.</div>Lorenzoghttps://wiki.archlinux.org/index.php?title=Lisp_package_guidelines_(Italiano)&diff=139333Lisp package guidelines (Italiano)2011-05-02T19:04:21Z<p>Lorenzog: /* ASDF */</p>
<hr />
<div>[[Category:Package development (Italiano)]]<br />
[[Category:Guidelines (Italiano)]]<br />
<br />
{{i18n|Lisp Package Guidelines}}<br />
{{translateme}}<br />
{{Nota|Questo articolo è in fase di traduzione. Seguite per ora le istruzioni della versione inglese.}}<br />
<br />
== Introduzione ==<br />
<br />
Attualmente ci sono relativamente pochi pacchetti lisp disponibili nei repository di Arch. Questo significa che prima o poi, probabilmente, se ne aggiungeranno altri. E' dunque utile pensare, adesso che ce ne sono pochi, a come dovrebbero essere pacchettizzati. Questa pagina vuole essere un punto di riferimento sulle linee guida per i pacchetti lisp. E' bene comunque tenere a mente che questa non è una versione definitiva; se non siete d'accordo con alcune idee suggerite qui, sentitevi liberi di modificare la pagina e proporre qualcosa di migliore.<br />
<br />
== Struttura delle cartelle e nomi ==<br />
<br />
C'è almeno un pacchetto nel repository base (libgpg-errpor) che include dei file lisp, che sono posizionati in '''/usr/share/common-lisp/source/gpg-error'''. Per conformità, gli altri pacchetti lisp dovrebbero installare i propri files in '''/usr/share/common-lisp/source/'''. Ogni pacchetto dovrebbe avere la propria cartella, in modo da non creare disordine in questa cartella di base.<br />
<br />
La cartella del pacchetto dovrebbe avere lo stesso nome del pacchetto lisp, e non dovrebbe essere nominata come nel repository Arch (o AUR). Questo si applica anche ai pacchetti costituiti soltanto da un file.<br />
<br />
Ad esempio, un pacchetto Lisp chiamato '''cl-ppcre''' dovrebbe essere nominato '''cl-ppcre'' in AUR e risiedere in '''/usr/share/common-lisp/source/cl-ppcre'''. Un pacchetto chiamato '''alexandria''' dovrebbe essere nominato '''cl-alexandria''' in AUR e risiedere in in '''/usr/share/common-lisp/source/alexandria'''.<br />
<br />
== ASDF ==<br />
<br />
Cercare di evitare l'utilizzo di ASDF-Install per l'installazione di questi pacchetti<br />
di sistema.<br />
<br />
ASDF può essere necessario o utile per la compilazione e/o il caricamento di pacchetti. In questo caso, è consigliabile che la cartella usata per il registro centrale (la posizione di tutti i link simbolici a *.asd) sia '''/usr/share/common-lisp/systems/'''.<br />
<br />
Sono stati riscontrati problemi effettuando la compilazione con asdf come parte del processo di compilazione di un pacchetto. Si può risolvere attraverso l'uso di un file package.install di questo tipo: <br />
<br />
# cl-ppcre.install<br />
# arg 1: the new package version<br />
post_install() {<br />
echo "---> Compiling lisp files <---"<br />
<br />
clisp --silent -norc -x \<br />
"(load #p\"/usr/share/common-lisp/source/asdf/asdf\") \<br />
(pushnew #p\"/usr/share/common-lisp/systems/\" asdf:*central-registry* :test #'equal) \<br />
(asdf:operate 'asdf:compile-op 'cl-ppcre)"<br />
<br />
echo "---> Done compiling lisp files <---"<br />
<br />
cat << EOM<br />
<br />
To load this library, load asdf and then place the following lines<br />
in your ~/.clisprc.lisp file:<br />
<br />
(push #p"/usr/share/common-lisp/systems/" asdf:*central-registry*)<br />
(asdf:operate 'asdf:load-op 'cl-ppcre)<br />
EOM<br />
}<br />
<br />
post_upgrade() {<br />
post_install $1<br />
}<br />
<br />
pre_remove() {<br />
rm /usr/share/common-lisp/source/cl-ppcre/{*.fas,*.lib}<br />
}<br />
<br />
op=$1<br />
shift<br />
<br />
$op $*<br />
<br />
Naturalmente, per far funzionare questo esempio, è necessario avere un link simbolico a package.asd nella cartella di sistema di asdf. Durante la compilazione del pacchetto, questo dovrebbe risolvere...<br />
<br />
pushd ${_lispdir}/systems<br />
ln -s ../source/cl-ppcre/cl-ppcre.asd .<br />
ln -s ../source/cl-ppcre/cl-ppcre-test.asd .<br />
popd<br />
<br />
...dove ''$_lispdir'' è '''${startdir}/pkg/usr/share/common-lisp'''.<br />
Creando un link con un path relativo piuttosto che assoluto, è possibile garantire che il link rimanga valido anche dopo l'installazione.<br />
<br />
== Lisp-specific packaging ==<br />
<br />
When possible, do not make packages specific to a single lisp<br />
implementation; try to be as cross-platform as the package itself will<br />
allow. If, however, the package is specifically designed for a single<br />
lisp implementation (i.e., the developers haven't gotten around to<br />
adding support for others yet, or the package's purpose is<br />
specifically to provide a capability that is built in to another lisp<br />
implementation), it is appropriate to make your Arch package<br />
lisp-specific.<br />
<br />
To avoid making packages implementation-specific, ideally all<br />
implementation packages (SBCL, cmucl, clisp) would be built with the<br />
PKGBUILD field '''common-lisp'''. However, that's not the case (and<br />
that would likely cause problems for people who prefer to have<br />
multiple lisps at their fingertips). In the meantime, you could (a)<br />
not make your package depend on *any* lisp and include a statement in<br />
the package.install file telling folks to make sure they have a lisp<br />
installed (not ideal), or (b) Take direction from the ''sbcl''<br />
PKGBUILD and include a conditional statement to figure out which lisp<br />
is needed (which is hackish and, again, far from ideal). Other ideas<br />
are welcome.<br />
<br />
Also note that if ASDF is needed to install/compile/load the package,<br />
things could potentially get awkward as far as dependencies go, since<br />
SBCL comes with asdf installed, clisp does not but there is an AUR<br />
package, and CMUCL may or may not have it (the author of this doc.<br />
knows next to nothing about CMUCL; sorry).<br />
<br />
People currently maintaining lisp-specific packages that don't need to<br />
be lisp-specific should consider doing at least one of the following:<br />
<br />
* Editing their PKGBUILD(s) to be cross-platform, provided someone else is not already maintaining the same package for a different lisp.<br />
<br />
* Offering to take over maintenance or help with maintenance of the same package for a different lisp, and then combining them into a single package.<br />
<br />
* Offering up their package to the maintainer of a different lisp's version of the same package, so as to allow that person to combine them into a single package.<br />
<br />
(Note that joyfulgirl, the author of this doc., currently maintains<br />
clisp versions of cl-ppcre and of stumpwm; she is open to either<br />
giving up the packages to the maintainers of the SBCL versions or to<br />
maintain the new, cross-platform versions herself if the SBCL-version<br />
maintainers don't want to).<br />
<br />
== Things you, the reader, can do ==<br />
<br />
* Maintain lisp packages following these guidelines<br />
* Update and fix problems with these guidelines<br />
* Keep up with what's changed here<br />
* Provide (polite) thoughts, feedback, and suggestions both on this document and to people's work.<br />
* Translate this page and future updates to this page.</div>Lorenzog