Quale file system Linux funziona meglio con SSD

Filesystem EXT4 + TRIM:

• EXT4 con TRIM migliora le prestazioni riducendo i cicli di scrittura non necessari sull'unità SSD poiché limitano i cicli di scrittura-riscrittura.
• Ubuntu e alcune altre versioni di Linux supportano EXT 4 con TRIM per impostazione predefinita.

Partizione SWAP:

• Assicurati di non avere uno spazio SWAP sull'SSD, sempre per ridurre i cicli di scrittura.
• Se disponi di un'unità meccanica, dovresti creare uno spazio SWAP sull'unità meccanica ed evitare di averlo sull'SSD.

Allineamento delle partizioni:

• La partizione dovrebbe iniziare su un limite pulito di 1 MB in modo che la dimensione del blocco del file system sia allineata con la dimensione del blocco dell'SSD.

Quindi usa EXT4 + TRIM con uno SWAP su un disco rigido meccanico o senza SWAP su SSD.

Quanto sopra può essere implementato facendo riferimento a Source:How to Maximize SSD Performance.

Risposta breve

• Scegli ext4 e montalo con discard opzione per il supporto TRIM o utilizza FITRIM (vedi sotto). Usa anche il noatime opzione se temi "l'usura dell'SSD".

• Non modificare il tuo pianificatore I/O predefinito (CFQ) su server con più applicazioni , poiché fornisce equità tra i processi e dispone del supporto SSD automatico. Tuttavia, usa Deadline sui desktop per ottenere una migliore reattività sotto carico.

• Per garantire facilmente un corretto allineamento dei dati, il settore iniziale di ogni partizione deve essere un multiplo di 2048 (=1 MB). Puoi usare fdisk -cu /dev/sdX per crearli. Nelle distribuzioni recenti, se ne occuperà automaticamente per te.

• Pensaci due volte prima di utilizzare lo scambio su SSD. Probabilmente sarà molto più veloce rispetto allo scambio su HDD, ma consumerà anche il disco più velocemente (il che potrebbe non essere rilevante, vedi sotto).

Risposta lunga

• Filesystem:

Est4 è il filesystem Linux più comune (ben mantenuto). Fornisce buone prestazioni con SSD e supporta il TRIM (e FITRIM) per mantenere buone prestazioni SSD nel tempo (questo cancella i blocchi di memoria inutilizzati per un rapido accesso in scrittura successivo). NILF è appositamente progettato per le unità di memoria flash, ma in realtà non funziona meglio di ext4 sui benchmark. Btrfs è ancora considerato sperimentale (e non funziona nemmeno meglio).

• Prestazioni SSD e TRIM:

Il TRIM la funzione 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. Il discard opzione di montaggio di ext4 emetterà tale TRIM comandi quando i blocchi del filesystem vengono liberati. Questo è scarto online .

Tuttavia, questo comportamento implica un piccolo sovraccarico di prestazioni. A partire da Linux 2.6.37, puoi evitare di usare discard e scegli di eseguire occasionali scarti batch con FITRIM invece (ad es. dal crontab). Il fstrim l'utility fa questo (online), così come il -E discard opzione di fsck.ext4 . Tuttavia, avrai bisogno di una versione "recente" di questi strumenti.

• Usura dell'SSD:

Potresti voler limitare le scritture sul tuo disco poiché SSD ha una durata limitata a questo proposito. Non preoccuparti troppo, comunque , 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 per allora.

Se vuoi usare scambia su SSD, il kernel noterà un disco non rotante e casualizzerà l'utilizzo dello swap (livellamento dell'usura a livello di kernel):vedrai quindi un SS (Solid State) nel messaggio del kernel quando lo scambio è abilitato:

Aggiunta di 2097148k swap su /dev/sda1. Priorità:-1 extent:1across:2097148k SS

• Programmatori I/O:

Inoltre, sono d'accordo con la maggior parte di aliasgar (anche se la maggior parte è stata -illegalmente?- copiata da questo sito web), ma devo dissentire in parte sullo programmatore parte. Per impostazione predefinita, lo scheduler delle scadenze è ottimizzato per dischi rotanti in quanto implementa l'algoritmo dell'elevatore. Quindi, chiariamo questa parte.

Risposta lunga sui pianificatori

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 per i dischi rigidi e 0 per un SSD.

Ora, lo scheduler CFQ può adattare il proprio comportamento in base a queste informazioni. A partire da Linux 3.1, la documentazione del kernel cfq-iosched.txt file 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 transito alla volta), [...].

Inoltre, lo scheduler Deadline tenta di limitare i movimenti non ordinati della testina 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 dati (lettura o scrittura) che vengono servite in ordine di settore crescente.

Tuttavia, l'ottimizzazione di questo parametro su 1 quando si utilizza un SSD può essere interessante:

Questo parametro ottimizza l'equilibrio tra la latenza per richiesta e la velocità effettiva aggregata. Quando la bassa latenza è la preoccupazione principale, più piccolo è meglio (dove un valore di 1 produce il comportamento primo arrivato, primo servito). L'aumento di fifo_batch generalmente migliora il throughput, a scapito della variazione della latenza.

Alcuni benchmark suggeriscono che c'è poca differenza nelle prestazioni tra i diversi scheduler. Allora, perché non raccomandare l'correttezza ? quando CFQ è raramente cattivo in panchina . Tuttavia, nelle configurazioni desktop, di solito riscontrerai una migliore reattività utilizzando Deadline sotto carico, grazie al suo design (probabilmente a un costo di throughput inferiore).

Detto questo, un benchmark migliore proverebbe a utilizzare Deadline con fifo_batch=1 .

Per utilizzare Deadline su SSD per impostazione predefinita, puoi 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"

L'articolo di archlinux Solid State Drives dice nella sezione Scelta del filesystem :

Esistono molte opzioni per i file system inclusi Ext2/3/4, Btrfs, ecc.

Btrfs
Il supporto Btrfs è stato incluso nella versione principale 2.6.29 del kernel Linux. Alcuni ritengono che non sia abbastanza maturo per l'uso in produzione, mentre ci sono anche i primi ad adottare questo potenziale successore di ext4. Gli utenti sono incoraggiati a leggere l'articolo di Btrfs per maggiori informazioni.

Est4
Ext4 è un altro filesystem che ha il supporto per SSD. È considerato stabile dal 2.6.28 ed è abbastanza maturo per l'uso quotidiano. Contrariamente a Btrfs, ext4 non rileva automaticamente la natura del disco; gli utenti devono abilitare esplicitamente il supporto del comando TRIM utilizzando l'opzione di montaggio discard in fstab (o con tune2fs -o scartare /dev/sdaX).

Sia Btrfs che Ext4 soddisfano i due principali requisiti per un uso efficiente dell'SSD:

• Il filesystem deve essere in grado di inviare comandi ATA_TRIM all'SSD sottostante
• Il filesystem non deve eseguire scritture non necessarie sul disco

Per le prestazioni, ci sono altri due requisiti :

• Le partizioni devono essere allineate alla dimensione del blocco dell'SSD
• TRIM deve essere esplicitamente abilitato per ogni partizione formattata Ext4

Il primo è oggigiorno automatico con la maggior parte degli installer Linux.fdisk creerà anche partizioni al limite di 1024KB se avviato con i flag "-cu".

Il secondo è automatico per Btrfs, ma per Ext4 questo viene fatto manualmente aggiungendo "discard" all'elenco delle opzioni di mount per ogni partizione Ext4 nel file "/etc/fstab". Per maggiori dettagli, vedi questo howto.

Secondo me, ciò ha richiesto un po' di manipolazione con fstab per Ext4 non è un motivo per non utilizzare questo filesystem maturo ed eccellente.