Risposta breve
Scegli ext4 e montalo con l' discard
opzione per il supporto TRIM , oppure usa FITRIM (vedi sotto). Utilizzare anche l' noatime
opzione se si teme "usura SSD".
Non modificare lo scheduler I / O predefinito (CFQ) su server multi-applicazioni , poiché fornisce equità tra i processi e dispone del supporto SSD automatico. Tuttavia, utilizzare Scadenza sui desktop per ottenere una migliore reattività sotto carico.
Per garantire facilmente un corretto allineamento dei dati, il settore iniziale di ciascuna partizione deve essere un multiplo di 2048 (= 1 MiB). Puoi usarli fdisk -cu /dev/sdX
per crearli. Nelle recenti distribuzioni, questo si occuperà automaticamente di questo.
Pensaci due volte prima di utilizzare lo scambio su SSD. Probabilmente sarà molto più veloce rispetto allo scambio su HDD, ma indosserà anche il disco più velocemente (il che potrebbe non essere rilevante, vedi sotto).
Risposta lunga
Ext4 è il filesystem Linux più comune (ben mantenuto). Fornisce buone prestazioni con SSD e supporta la funzione TRIM (e FITRIM) per mantenere buone prestazioni SSD nel tempo (questo cancella i blocchi di memoria non utilizzati per un rapido accesso successivo alla scrittura). NILFS è stato appositamente progettato per le unità di memoria flash, ma non senza in realtà prestazioni migliori rispetto ext4 sui parametri di riferimento. Btrfs è ancora considerato sperimentale (e in realtà non prestazioni migliori sia ).
La funzione TRIM cancella i blocchi SSD che non sono più utilizzati dal filesystem. Ciò ottimizzerà le prestazioni di scrittura a lungo termine ed è consigliato su SSD a causa del loro design. Significa che il filesystem deve essere in grado di dire all'unità di quei blocchi. L' discard
opzione mount di ext4 emetterà tali comandi TRIM quando i blocchi del filesystem vengono liberati. Questo è scarto online .
Tuttavia, questo comportamento implica un leggero sovraccarico di prestazioni. A partire da Linux 2.6.37, è possibile evitare di utilizzare discard
e scegliere invece di eseguire scarti batch occasionali con FITRIM (ad es. Dal crontab). L' fstrim
utilità esegue questa operazione (online) e l' -E discard
opzione di fsck.ext4
. Tuttavia, avrai bisogno della versione "recente" di questi strumenti.
Potresti voler limitare le scritture sul tuo disco poiché SSD ha una durata limitata in questo senso. Tuttavia , non preoccuparti troppo , il peggior SSD da 128 GB di oggi può supportare almeno 20 GB di dati scritti al giorno per più di 5 anni (1000 cicli di scrittura per cella). Quelli migliori (e anche quelli più grandi) possono durare molto più a lungo: molto probabilmente lo avrai sostituito da allora.
Se vuoi usare lo swap su SSD, il kernel noterà un disco non rotazionale e randomizzerà l'uso dello swap (livellamento dell'usura a livello del kernel): vedrai un SS
(Stato solido) nel messaggio del kernel quando lo swap è abilitato:
Aggiunta dello scambio 2097148k su / dev / sda1. Priorità: -1 estensioni: 1 attraverso: 2097148k SS
Inoltre, sono d'accordo con la maggior parte della risposta di aliasgar (anche se la maggior parte è stata -illegalmente? - copiata da questo sito Web ), ma devo essere in parte in disaccordo con la parte dello scheduler . Per impostazione predefinita, lo scheduler delle scadenze è ottimizzato per i dischi rotazionali poiché implementa l' algoritmo dell'elevatore . Quindi, chiariamo questa parte.
Risposta lunga sugli scheduler
A partire dal kernel 2.6.29, i dischi SSD vengono rilevati automaticamente e puoi verificarlo con:
cat /sys/block/sda/queue/rotational
Dovresti ottenere 1
dischi rigidi e 0
un SSD.
Ora, lo scheduler CFQ può adattare il suo comportamento sulla base di queste informazioni. Da linux 3.1, il cfq-iosched.txt
file della documentazione del kernel dice :
CFQ ha alcune ottimizzazioni per gli SSD e se rileva un supporto non rotazionale in grado di supportare una maggiore profondità della coda (più richieste in volo alla volta), [...].
Inoltre, lo schedulatore Deadline cerca di limitare i movimenti della testa non ordinati sui dischi rotazionali, in base al numero di settore. Citando il documento del kernel deadline-iosched.txt
, fifo_batch
descrizione dell'opzione :
Le richieste sono raggruppate in `` batch '' di una particolare direzione dei dati (lettura o scrittura) che vengono gestite in ordine crescente di settore.
Tuttavia, sintonizzare questo parametro su 1 quando si utilizza un SSD può essere interessante:
Questo parametro regola l'equilibrio tra latenza per richiesta e throughput aggregato. Quando la latenza bassa è la preoccupazione principale, minore è meglio (dove un valore di 1 produce un comportamento di primo arrivato, primo servito). L'aumento di fifo_batch generalmente migliora la velocità effettiva, a scapito della variazione di latenza.
Alcuni benchmark suggeriscono che c'è poca differenza nelle prestazioni tra i diversi programmatori. Quindi, perché non raccomandare l' equità ? quando il CFQ è raramente male in panchina . Tuttavia, nelle configurazioni desktop, di solito si verificherà una migliore reattività utilizzando Deadline sotto carico, a causa del suo design (probabilmente a un costo di throughput inferiore però).
Detto questo, un benchmark migliore proverebbe a utilizzare Deadline con fifo_batch=1
.
Per utilizzare Deadline su SSD per impostazione predefinita, è possibile creare un file, ad esempio /etc/udev.d/99-ssd.rules
come segue:
# all non-rotational block devices use 'deadline' scheduler
# mostly useful for SSDs on desktops systems
SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="deadline"
gdisk
&grub 2.0.x
, (immagino che qualcuno lo abbia menzionato di seguito in una risposta) e MBR è il metodo legacy che utilizza il vecchiogrub 0.9.7
efdisk
.. puoi trovare di più qui: wiki.archlinux.org/index.php/Solid_State_Drives