Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Ein PPA freischalten, optional
Kompilieren von Programmen, optional
Archive entpacken, optional
Dieser Artikel soll einen kurzen Überblick verschaffen, wie eine SD-Karte für optimale Geschwindigeit vorzubereiten ist, um darauf ein Ubuntu-/Linuxsystem optimal zu betreiben. Der Artikel selber versteht sich als Vorbereitung für die Installation auf externen Speichermedien.
Da Linux standardmäßig für die Nutzung auf klassischen Festplatten optimiert ist, soll dieser Artikel dabei helfen, Zugriffszeiten und Schreibzugriffe zu reduzieren bzw. zu optimieren. Während bei einer normalen Festplatte bei Änderungen einer Datei nur die zu ändernden Daten neu geschrieben bzw. erweitert werden, müssen bei einer SD-Karte ganze Bereiche ausgelesen und neu geschrieben werden. Dieses mag bei großen Dateien unwichtig sein (ob nun 1004 MiB statt 1000 MiB neu geschrieben werden), aber wenn viele kleine Dateien geschrieben werden müssen (z.B. 3 Logdateien à 4 KiB = 12 KiB oder 3 × 4 MiB = 12 MiB), die verteilt auf der SD-Karte liegen, führt dieses zu erheblichen Geschwindigkeitseinbrüchen beim Schreibvorgang. Um dieses zu verhindern, kann das Speichermedium dahingehend optimiert werden, Schreibvorgänge vorzuhalten und erst ab einer gewissen Größe diese, sozusagen "in einem Rutsch", abzuarbeiten.
Es empfiehlt sich, die SD-Karte nicht während der Installation, sondern bereits im Vorfeld entsprechend zu optimieren. Die benötigten Daten zur optimalen Partitionierung liefert das Werkzeug Flashbench .
Da Speicherkarten bzw. -Sticks grundsätzlich, bis auf extrem teure Sonderausführungen, relativ langsam im Vergleich zu Festplatten sind, empfiehlt es sich immer, Lubuntu bzw. Xubuntu als Grundsystem für die Installation zu nutzen. Diese Systeme sind für die Verwendung auf leistungsschwacher Hardware ausgelegt. Außerdem empfiehlt sich mindestens eine SD-Karte der Geschwindigkeitskategorie Class 6 oder höher!
Im Folgenden ist /DEV/SD_KARTE
immer durch den tatsächlichen Datenträger zu ersetzen. /dev/SD_KARTE1
, /dev/SD_KARTE2
, usw. sind verschiedene Partitionen (siehe auch Systeminformationen ermitteln).
Das Programm ist ab Ubuntu 14.04 Bestandteil der offiziellen Paketquellen. Folgendes Paket muss installiert werden [1]:
flashbench (universe)
mit apturl
Paketliste zum Kopieren:
sudo apt-get install flashbench
sudo aptitude install flashbench
Nun stehen die beiden Programme flashbench und flashbench-erase zur Verfügung.
Für Ubuntu 12.04 steht ein inoffizielles PPA [2] zur Verfügung, über das Flashbench installiert werden kann.
Adresszeile zum Hinzufügen des PPAs:
ppa:lasall/flashbench
Zusätzliche Fremdquellen können das System gefährden.
Ein PPA unterstützt nicht zwangsläufig alle Ubuntu-Versionen. Weitere Informationen sind der PPA-Beschreibung des Eigentümers/Teams lasall zu entnehmen.
Damit Pakete aus dem PPA genutzt werden können, müssen die Paketquellen neu eingelesen werden.
Nach dem Aktualisieren der Paketquellen erfolgt die Installation wie oben angegeben.
Zum Kompilieren [3] aus dem Quellcode wird folgendes Metapaket benötigt:
build-essential
mit apturl
Paketliste zum Kopieren:
sudo apt-get install build-essential
sudo aptitude install build-essential
Jetzt muss die aktuelle Version von Flashbench als Archivdatei linaro.zip heruntergeladen und anschließend entpackt [4] werden.
Nun wird ein Terminal geöffnet und in das entpackte Verzeichnis gewechselt (XYZ
ist entsprechend der Version anzupassen). Das Programm wird durch Eingabe des Befehles make
kompiliert [5]:
cd flashbench-XYZ make
Nun stehen im selben Verzeichnis 2 neue ausführbare Dateien zu Verfügung: flashbench und erase.
-rw-rw-r-- 1 user user 18092 Aug 10 00:10 COPYING -rw-rw-r-- 1 user user 2872 Aug 10 00:10 dev.c -rw-rw-r-- 1 user user 521 Aug 10 00:10 dev.h -rw-rw-r-- 1 user user 15968 Aug 10 00:13 dev.o -rwxrwxr-x 1 user user 13004 Aug 10 00:13 erase -rw-rw-r-- 1 user user 679 Aug 10 00:10 erase.c -rw-rw-r-- 1 user user 11208 Aug 10 00:13 erase.o -rwxrwxr-x 1 user user 98129 Aug 10 00:13 flashbench -rw-rw-r-- 1 user user 22024 Aug 10 00:10 flashbench.c -rw-rw-r-- 1 user user 86176 Aug 10 00:13 flashbench.o -rw-rw-r-- 1 user user 364 Aug 10 00:10 Makefile -rw-rw-r-- 1 user user 5085 Aug 10 00:10 README -rw-rw-r-- 1 user user 17196 Aug 10 00:10 vm.c -rw-rw-r-- 1 user user 1576 Aug 10 00:10 vm.h -rw-rw-r-- 1 user user 68288 Aug 10 00:13 vm.o
Nun kann mit Flashbench schnell und sicher die Erasureblockgröße von Flashmedien ermittelt werden. Je nachdem, ob Flashbench nur kompiliert oder richtig installiert wurde, werden folgende Befehle zum Starten benötigt [3]:
Flashbench nach Installation ausführen:
sudo flashbench -a /dev/SD_KARTE --blocksize=1024
Flashbench nach Kompiliervorgang im Quellverzeichnis ausführen:
sudo ./flashbench -a /dev/SD_KARTE --blocksize=1024
(verkürzte) Ausgabe Flashbench | |||||
align | pre | on | post | diff | |
8 MiB | 8388608 | 724µs | 1.04ms | 768µs | 299µs |
4 MiB | 4194304 | 741µs | 1.08ms | 788µs | 317µs |
2 MiB | 2097152 | 745µs | 950µs | 811µs | 171µs |
1 MiB | 1048576 | 745µs | 945µs | 807µs | 169µs |
Die Ausgabe ist auf einen "Sprung" in der letzten Spalte (diff) abzusuchen (normalerweise zwischen 2 und 16 MiB). In diesem Beispiel sieht man zwischen 2 MiB und 4 MiB einen plötzlichen Anstieg der Differenzzeiten von 171µs auf 317µs. In diesem Beispiel ist 4 MiB die Erasureblockgröße, mit der ab hier gerechnet wird.
Als Erasureblock wird der Block bezeichnet, welcher bei allen Flashmedien komplett ausgelesen und neu geschrieben werden muss, um Daten auf einem Flashmedium zu ändern. Hinkendes Beispiel: Um einen "Plattfuß" am PKW zu beheben, müssen alle 4 Reifen (4 MiB-Block) ab- und wieder angeschraubt werden, obwohl eigentlich nur ein Reifen (1 Bit) gewechselt werden muss.
Kurze Übersicht der Werte, mit denen im weiteren Verlauf gearbeitet wird:
Ermittelte Werte | ||
Erasureblocksize | 4 MiB | gemessen mit Flashbench |
SD-Karten Pagesize | 8 KiB | Standardwert von SD-Karten |
Blocksize ext4 | 4 KiB | |
stride-Wert ext4 | 2 | 2x Blocksize 4KiB = 8 KiB Pagesize |
stripe-size ext4 | 512 | |
optimale Sektorgröße | 8192 | jede Partition muss auf ein Vielfaches von 8192 beginnen: 4 MiB (4*1024*1024 Byte) Erasursize / 512 Byte Größe einzelner Sektor = 8192 Sektoren |
Beim Formatieren des Datenträgers gehen alle darauf befindlichen Daten verloren.
Mit parted steht ein Tool zur Verfügung, dass das manuelle Rechnen für optimales Alignment erspart.
Zuerst wird in den interaktiven Modus für den entsprechenden Datenträger gewechselt:
sudo parted -a optimal /dev/SD_KARTE
Anschließend wird eine neue Partitionstabelle erstellt:
mklabel msdos
Und dann die Einheit für Ein- und Ausgabeformat auf das besser lesbare MiB gesetzt.
unit MiB
Anschließend wird die erste Partition angelegt. STARTWERT
und ENDWERT
sind dabei Anfangs- und Endwert vom Anfang des Datenträgers gemessen und werden in MiB angegeben. Die Differenz STARTWERT - ENDWERT
muss durch den mit Flashbench ermittelten Wert teilbar sein. Für den Bootloader sollten am Anfang der Platte mindestens ca. 2 MiB freigelassen werden:
mkpart primary ext4 STARTWERT ENDWERT
Alle weiteren Partitionen werden mit dem selben Befehl erstellt, aber mit angepassten Start- und Endwerten. Welche Größe die Partitionen haben müssen/sollten und welche Partitionen nötig sind, wird im Artikel Partitionierung erklärt.
Anschließend wird von Units auf Sektoren umgestellt:
unit s
Nun sollte die Konfiguration überprüft werden:
Die Partitionen sollten nun jeweils auf einer ungeraden Zahl enden, damit die nachfolgende Partition auf einem Vielfachen der optimale Sektorgröße (im Beispiel 8192) beginnen kann!
Mit
align-check opt N
kann nachgeschaut werden, ob die Partition N
(natürliche Zahl) korrekt ausgerichtet ist. Ist dies der Fall, sieht man eine Ausgabe der Form:
1 aligned
Nun müssen die Dateisysteme für die erstellten Partitionen, z.B. für / und /home mit den oben ermittelten Werten angelegt werden:
sudo mkfs.ext4 -O^has_journal -E stride=2,stripe-width=512 -b 4096 -L SDroot /dev/SD_KARTE1 sudo mkfs.ext4 -O^has_journal -E stride=2,stripe-width=512 -b 4096 -L SDhome /dev/SD_KARTE2
Erklärung der Parameter:
mkfs.ext4 Parameter | |
-O ^has_journal | kein Journal anlegen |
-E Stride=2,stripe-width=512 | Stride=2 bedeutet 2x 4096 Byte Blockwidth = 8 KiBstripe-width=512 ist der Erasurewert -> 512 (*8 KiB Blockwidth=4 MiB Erasuresize) |
-b | Blockwidth 4096 Byte |
-L | Name der Partition (optional) |
Nun ist die SD-Karte sowohl entsprechend ausgerichtet (Alignment) als auch das Dateisystem entsprechend modifiziert. Das Grundsystem kann nun installiert werden.
Während der Installation ist darauf zu achten, das als Installationsart "etwas anderes" angeklickt wird und die Partitionen nicht formatiert werden!
Nach der Installation sollten/können noch einige Parametern geändert werden. Dazu sind die folgenden Dateien mit dem Editor zu bearbeiten:
Datei | Ergänzen/Bearbeiten | Auswirkung |
/etc/sysctl.conf | vm.swappiness=0 | Auslagerung auf die Swap-Partition maximal hinauszögern |
vm.vfs_cache_pressure=50 | 50% RAM reservieren für das Cachen/Vorhalten von Dateien | |
vm.dirty_ratio=40 | in %, Speicherbelegung für Vordergrund-Schreibcache | |
vm.dirty_background_ratio=20 | in %, Speicherbelegung Hintergrund-Schreibcache | |
vm.dirty_writeback_centisecs=12000 | Achtung!Datenverlust. Zwingt das System, geplante Schreibvorgänge auf der Festplatte solange vorzuhalten, bis der Wert abgelaufen ist. Problematisch bei einem plötzlichem Absturz des Systems ist, das möglicherweise die komplette Zeitspanne in den Logdateien fehlt und die Fehlersuche somit wesentlich erschwert wird bzw. Produktivdaten, welche vorgehalten, aber noch nicht geschrieben wurden, verloren gehen! | |
/etc/default/grub | GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop" (erweitert um elevator=noop , siehe GRUB 2/Konfiguration)Anschließend GRUB aktualisieren. | Weist den Kernel an, die Schreibverwaltung an den Hypervisor zu übergeben. |
Für weitere Optimierungsmöglichkeiten empfiehlt sich ein Blick ins Wiki zum Thema SSD-Festplatten.
Aligning an SSD on Linux - Blogbeitrag, 12/2009
Tuning The VM (memory) Subsystem - Blogbeitrag, 10/2009
elevator=noop - Blogbeitrag, 02/2008
SSD Übersichtsartikel
Installation Übersichtsartikel
Diese Revision wurde am 8. Juni 2016 19:10 von aasche erstellt.