Soll ich btrfs oder Ext4 für meine SSD verwenden?


16

Soll ich btrfs (mit den Optionen discard, compress = lzo und space_cache) oder Ext4 (mit der Option discard) für die SSD für meine Ubuntu 11.10 (Oneiric) amd64-Desktop-Root-Partition meines Office-Computers verwenden?

/ home wird eine Festplatte sein, daher wirkt sich die Zuverlässigkeit des Betriebssystems nicht auf meine Daten aus.

Antworten:


13

Nach den Tests von phoronix kommt es immer auf viele Faktoren an. In einem Fall Btrfsist dies viel besser als EXT4beim Lesen großer Dateien auf einer SSD. In ähnlicher Weise Ext4kann die Leistung von Festplattentransaktionen besser sein als die von späteren.

Sie können diese Tests hier , hier und hier durchsehen (WARNUNG: Lange Artikel).

Zusammenfassend hat Btrfs derzeit jedoch keinen quantitativen Leistungsvorteil gegenüber dem EXT4-Dateisystem , selbst wenn es im SSD-Modus verwendet wird.

So können Sie vorerst wählen Ext4.


2
Die Artikel sind September 2011, 9. August 2010 und 29. Mai 2009. Konzentration auf das Neueste, da ich davon ausgehe, dass sich btrfs in den letzten 2 Jahren weiterentwickeln würde. Das btrfs + LZO-Diagramm auf Seite 4 ist erstaunlich für die sequentielle Lese- und Schreibleistung, aber btrfs verträgt sich schlecht mit zufälligen Schreibvorgängen, sodass es definitiv nicht mit btrfs für DBs und VM-Images zu tun hat. Ich denke, mit Root-Partition ist die Last meistens zufällig gelesen, für die es nicht viel besser als ext4 ist.
Graham

Innerhalb weniger Jahre wird sich Btrfs zu einer besseren Option als EXT4 entwickeln. Es ist ein vielversprechenderes Dateisystem :)
NBK

7

Für diejenigen, die 2016 über diese Frage stolpern ... Verwenden Sie ext4. Ich habe btrfs ausprobiert und der Unterschied ist erheblich. In einem Zeitraum von 10 Tagen beliefen sich die E / A-Schreibvorgänge für ext4 auf 17.800 Sektoren. Btrfs? 490.400 Sektoren. Gleiche SSD, identisches Dateisystem, verschiedene Partitionen. Grundsätzlich gleiche Arbeitsbelastung.

Sowohl ext4 als auch btrfs werden "leise", wenn keine Schreibaktivität auf dem Laufwerk vorhanden ist. Das ist gut.

Ext4 schreibt die geänderten Daten plus etwas Overhead. Gemeinkosten beziehen sich auf die geschriebenen Daten. Ein 4-KByte-Schreibzugriff (1 Block) verursacht beim nächsten Festschreiben einen Overhead von ca. 50-80 Blöcken. (Das ext4 Journal ist voll aktiviert)

Wenn Sie einen einzelnen 4-KByte-Block in btrfs ändern, werden Sie beim nächsten Festschreiben einen Push zwischen 4000 und 5000 Overhead-Blöcken ausführen. Das Standard-Commit dauert meiner Meinung nach 30 Sekunden. Ich habe 120 benutzt.

Jetzt hängt es davon ab, wie Sie die SSD verwenden. Als Root gibt es normalerweise einen relativ konstanten Strom von Schreibvorgängen auf niedriger Ebene. Protokolldateien, NTP-Drift-Dateien, Man-DB-Neuerstellungen, OpenSM-Topologie-Updates usw. Jedes Ereignis wird ein BTRFS-Laufwerk mit weiteren 4000-5000 Schreibvorgängen hämmern.

Die obigen 10-Tage-Nummern gelten für meine SSD mit Schreibbeschränkung. Der Großteil dieser 17.800 Sektoren war das Ergebnis einer geringfügigen Systemaktualisierung. Eine der btrfs-Kopien hat nicht gelitten. Meine Autoren sind genau genommen NTP-Drift, OpenSM-Topologie und Man-DB-Updates (nächtlich). Nichts anderes trifft diese Festplatte außer aktiv initiierten Dingen wie System-Upgrades, "vim / etc / whatever" usw.

Auf ganzen SSDs wird es wirklich viele Schreibvorgänge geben. Ich kann es einfach nicht verstehen, sie zu verschwenden, nur weil die Nachrichtenmedien Hasen und Regenbogen jagen. Wenn Sie diesen Preis für die Kuh bezahlen möchten, entscheiden Sie sich dafür. Für "Leistung" nicht so sehr. Es ist eine SSD, und Sie könnten wahrscheinlich das schlimmste "Dateisystem", das der Mensch kennt, darauf ablegen und trotzdem eine gewisse Leistung erzielen - nur mit brachialer Gewalt. Ext4 ist bei weitem nicht das schlechteste Dateisystem, das man kennt.

Kein monatlicher fs check. Probieren Sie das folgende Skript aus. Es ist ein 100% Hack, funktioniert nicht für md Mountpoints,

#! /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, gemountet auf $ 1 (vmstat auf $ vmnam)"

tim =date +%s

timx =date +%s

während wahr

tun

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 

erledigt

Hier erfahren Sie, wie viele Blöcke je nach Laufwerk selbst geschrieben wurden und welche Dateien genau aktualisiert wurden. Benötigt root-Rechte. Überzeugen Sie sich selbst. Ich führe eine SSD im Root-Dateisystem aus und rufe das Skript stat.sh auf. Also ... "sudo ./stat.sh /"


Ihre Vergleichsmethode gefällt mir nicht. Zum Beispiel hat der monatliche fs-Check begonnen und Sie haben diese Ergebnisse erhalten. Btrfs ist mittlerweile fast überall Standard, und das aus gutem Grund.
Barafu Albino

Kein monatlicher fs check. Probieren Sie das folgende Skript aus. Es ist ein 100% Hack, funktioniert nicht für md Mountpoints, etc ...
wkirk

1
Warum so ein großer Schreibaufwand? Sie haben angegeben, dass 1 Block 50-80 Blöcke erstellt hat, die sogar auf ext4 geschrieben wurden - das ist 40-mal mehr als benötigt. Warum?
Golar Ramblar

Ich frage mich, ob dies Ende 2018 noch zutrifft. In meinem Test habe ich den nach iotop und smartctl geschriebenen Betrag verglichen und festgestellt, dass letzterer das 3-fache des ersteren (ext4) beträgt.
Michael

2

Das letzte Mal, als ich es getestet habe und noch nirgendwo anders gehört habe, isst ext4 Solid-State-Medien. (Thumbdrives, Solid-State-Laufwerke usw.) Ich empfehle nicht, es auf einem solchen Gerät zu verwenden. Verwenden Sie stattdessen ext3. In den meisten Fällen können Sie auf einer SSD ohnehin keinen Unterschied feststellen.

BTRFS ist noch nicht ganz stabil. Es ist jedoch stabil genug für nicht kritische Anwendungen. Ich verwende es, um bootfähige Flash-Laufwerke zu erstellen. Wenn Sie compress = zlib und ssd als Mount-Optionen verwenden, gleicht die Komprimierung die niedrigeren Schreibgeschwindigkeiten der meisten Solid-State-Medien aus, und die ssd ändert den Zuweisungsalgorithmus in einen Algorithmus, der auf solchen Geräten eine deutlich bessere Leistung erbringt und alle ausgleichen wird schlechter Verschleiß durch die Hardware. Der einzige Leistungsbereich, der immer noch ein Problem darstellt, ist, dass Synchronisierungsaufrufe langsam sind. Dies ist kein Problem für den allgemeinen Gebrauch, aber dpkg ruft nach jedem Vorgang die Synchronisierung auf, sodass die Installation und Aktualisierung von Software langsam sein kann. BTRFS bietet auch Schnappschüsse und andere erweiterte Funktionen, die unter bestimmten Umständen sehr nützlich sind.

Wenn Sie sich für BTRFS entscheiden, stellen Sie sicher, dass Sie eine Distribution mit Kernel 3.2.0-2 oder höher verwenden. 3.1.x ist bei Bedarf funktionsfähig. Für ältere Kernel müssen Sie die neuesten BTRFS-Module selbst kompilieren. Die eingebauten sind fast stabil, aber die Fehlerkorrektur funktioniert in den älteren Versionen nicht, was dazu führen kann, dass Sie einen Bach hochlaufen, wenn etwas schief geht. Die neuesten Versionen haben fsck, mit dem die häufigsten Fehler behoben werden können.

Eine letzte Einschränkung, ich habe gehört, Berichte, dass Swap-Dateien auf einem BTRFS-Dateisystem es beschädigen. Dieses Problem wurde möglicherweise behoben, aber prüfen Sie es sorgfältig, bevor Sie es implementieren.

Wenn Sie Hilfe benötigen, um ein BTRFS-Setup wie gewünscht zu konfigurieren, lassen Sie es mich wissen. Ich habe ein paar verrückte gemacht, die für bestimmte Dinge ziemlich gut funktionieren.


2

Ich würde ext4 nicht auf einem Solid-State-Laufwerk verwenden, das auf Einzelfällen basiert, und meine eigenen Erfahrungen legen nahe, dass ext4 die Lebensdauer einer SSD aufgrund der Anzahl der mit dem Dateisystem verbundenen Lese- und Schreibvorgänge erheblich verkürzen kann. Ein Artikel, den ich kürzlich gelesen habe, schlug vor, dass nicht optimiertes ext4 auf einer SSD (unter Berücksichtigung der Seitengröße usw.) die Lebensdauer der Festplatte halbieren kann. Nach einer Woche der Fehlerbehebung bin ich zu dem Schluss gekommen, dass meine eigenen SSDs aufgrund dieses Problems nur acht Monate gedauert haben. Wenn Sie eine SSD verwenden, lesen Sie viel darüber, wie Sie das Dateisystem auf der Grundlage von Elementen wie der Größe der Flash-Seite optimieren, die sich möglicherweise von der typischen Zylindergröße unterscheidet, für die das Dateisystem eingerichtet ist.


2
Können Sie einen Link oder andere identifizierende Informationen für den Artikel bereitstellen, den Sie gelesen haben?
Eliah Kagan

Ich werde versuchen, diesen Artikel speziell zu finden. Bitte denken Sie daran, dass diese Aussage im Internet gefunden wurde, als Sie im Zigarrenladen gesurft haben. Machen Sie Ihre Lese- und Hausaufgaben, bevor Sie ext4 auf einer SSD verwenden. Schauen Sie sich die Artikel zu Themen wie TRIMM und Optimierung an. Was auch immer Sie tun, seien Sie nicht wie ich und erhalten Sie nach acht Monaten E / A-Fehler bei Befehlen wie "sudo reboot".
User75153
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.