Dovrei usare btrfs o Ext4 per il mio SSD?

Dovrei usare btrfs (con le opzioni discard, compress = lzo e space_cache) o Ext4 (con l'opzione discard) per l'SSD per la mia partizione root desktop Ubuntu 11.10 (Oneiric) amd64 della mia macchina da ufficio?

/ home sarà un HDD, quindi l'affidabilità fs influisce sul sistema operativo e non sui miei dati.

Secondo i test di phoronix dipende sempre da molti fattori. In un caso Btrfsandrà molto meglio rispetto EXT4alla lettura di file di grandi dimensioni su un SSD. Allo stesso modo, considerando le prestazioni delle transazioni su disco, Ext4può funzionare meglio delle versioni successive.

Puoi dare un'occhiata a questi test qui , qui e qui (ATTENZIONE: articoli lunghi).

Ma sommando tutto, Btrfs in questo momento non ha un vantaggio quantitativo in termini di prestazioni rispetto al file system EXT4 , anche quando si utilizza in modalità SSD.

Quindi puoi scegliere oltre Ext4per ora.

Per coloro che si imbattono in questa domanda nel 2016 ... Usa ext4. Ho provato btrfs e la differenza è sostanziale. In un periodo di 10 giorni scrivere IO su ext4 ammonta a 17.800 settori. Btrfs? 490.400 settori. Stesso SSD, file system identico, partizioni diverse. Fondamentalmente, stesso carico di lavoro.

Sia ext4 che btrfs diventano "silenziosi" quando non vi è alcuna attività di scrittura sull'unità. Quello è buono.

Ext4 scriverà i dati modificati, oltre ad alcune spese generali. Le spese generali si riferiscono ai dati scritti. Una scrittura 4K (1 blocco) spinge circa 50-80 blocchi di overhead al prossimo commit. (Il journal ext4 è completamente abilitato)

Modifica un singolo blocco 4K su btrfs e al prossimo commit passerai tra 4000-5000 blocchi di overhead. Il commit predefinito è di 30 secondi, credo. Ho usato 120.

Ora dipende da come usi l'SSD. Come root, c'è in genere un flusso abbastanza costante di basso livello di scritture in corso. File di registro, file di deriva ntp, ricostruzioni man db, aggiornamenti di topologia opensm, ecc. Ecc. Ogni evento martellerà un'unità btrfs con altre 4000-5000 scritture.

I numeri di 10 giorni sopra indicati sono per il mio SSD "write limited". La maggior parte di questi 17.800 settori erano il risultato di un aggiornamento del sistema di piccole dimensioni. Uno della copia di btrfs non ha sofferto. I miei scrittori sono, esattamente, ntp drift, opensm topology e man db updates (nightly). Nient'altro colpisce quel disco, tranne cose avviate attivamente come aggiornamenti di sistema vim /etc/whatever, ecc.

Nel complesso, gli SSD subiranno molte scritture, davvero. Non riesco proprio a capire il motivo di sprecarli solo perché i media stanno inseguendo coniglietti e arcobaleni. Se vuoi pagare questo prezzo per COW, provalo. Per "performance", non tanto. È un SSD e probabilmente potresti mettere il peggior "file system" conosciuto dall'uomo su di esso, e ottenere comunque un certo livello di prestazioni - solo con la forza bruta. Ext4 non è di gran lunga il peggior file system conosciuto dall'uomo.

Nessun controllo mensile fs. Prova lo script qui sotto. È un hack al 100%, non funzionerà con mountpoint md,

#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
    vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
    lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
    if [ "$vm" != "$vmx" ]
    then
        tim=`date +%s`
        dif=`dc <<< "$vm $vmx - p"`
        lbad=`dc <<< "$lba $lbax - p"`
        timd=`dc <<< "$tim $timx - p"`
        echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
        vmx="$vm"
        lbax="$lba"
        timx="$tim"
        find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
        touch "$tmpnam" 
    fi
    sleep 1 
done

Ti dirà quanti blocchi sono stati scritti, in base all'unità stessa, ed esattamente quali file sono stati aggiornati. Ha bisogno di privilegi di root. Guarda tu stesso. Corro SSD sul filesystem di root e chiamo lo script stat.sh. Così...sudo ./stat.sh /

L'ultima volta che l'ho provato, e non ho ancora sentito diversamente da nessuna parte, ext4 mangia media a stato solido. (levette, unità a stato solido, ecc.) Non consiglio di usarlo su un dispositivo del genere. Usa ext3 invece. Nella maggior parte dei casi su SSD non sarai in grado di distinguere comunque.

BTRFS non è ancora abbastanza stabile. Tuttavia, è abbastanza stabile per applicazioni non critiche. È quello che uso per creare unità flash avviabili. Se usi compress = zlib e ssd come opzioni di montaggio, la compressione compenserà le velocità di scrittura inferiori della maggior parte dei supporti a stato solido e ssd modifica l'algoritmo di allocazione in uno che offre prestazioni significativamente migliori su tali dispositivi e compenserà qualsiasi scarso livellamento dell'usura da parte dell'hardware. L'unica area di prestazioni che è ancora un problema è che le chiamate di sincronizzazione sono lente. Questo non è un problema per uso generale, ma le chiamate dpkg si sincronizzano dopo ogni operazione, quindi l'installazione e l'aggiornamento del software possono essere lenti. BTRFS offre anche snapshot e altre funzionalità avanzate che sono abbastanza utili in determinate circostanze.

Se decidi di usare BTRFS, assicurati di usare una distro usando il kernel 3.2.0-2 o successivo. 3.1.x è realizzabile se necessario. Per i kernel più vecchi dovrai compilare tu stesso i moduli BTRFS più recenti. Quelli integrati sono quasi stabili, ma la correzione degli errori non funziona nelle versioni precedenti, il che può lasciarti in un insenatura se qualcosa va storto. Le ultime versioni hanno fsck che può effettivamente riparare i guasti più comuni.

Un ultimo avvertimento, ho sentito che i file di scambio su un filesystem BTRFS lo corromperanno. Questo problema potrebbe essere stato risolto, ma assicurati di controllare attentamente prima di implementarne uno.

Se hai bisogno di aiuto per configurare un'impostazione BTRFS nel modo che preferisci, fammi sapere. Ho fatto un paio di pazzi che funzionano piuttosto bene per cose specifiche.

Non userei ext4 su un disco a stato solido basato su prove aneddotiche e la mia esperienza che suggerisce ext4 può ridurre notevolmente la durata di un SSD a causa del numero di letture e scritture associate al file system. Un articolo che ho letto di recente ha suggerito che ext4 non ottimizzato (tenendo conto della dimensione della pagina, ecc.) Su un SSD può dimezzare la durata del disco. Dopo una settimana di risoluzione dei problemi, sono giunto alla conclusione che i miei SSD sono durati solo otto mesi a causa di questo problema. Se si utilizza un SSD, leggere attentamente come ottimizzare il file system in base a elementi come le dimensioni della pagina flash che potrebbero essere diverse dalla dimensione tipica del cilindro per cui è configurato il file system.