Oskar Welzl: Weblog zur Homepage

[Ich werde] mir eine SD-Karte fürs Telefon zulegen und Dateien in Zukunft dort statt im home-Verzeichnis speichern.

Gesagt, getan, ein Mann, ein Wort (widedidewitt bum bum). Auf der Mariahilfer Straße flanieren, SD-Karte kaufen … und ab ins Abenteuer. :)

SD-Karten, die Grundlagen

Zunächst muß man wissen: SD-Karte ist nicht SD-Karte. Abgesehen von den offensichtlichen Unterschieden im Format (SD, mini-SD und micro-SD) gibt es noch drei technische Spezifikationen:

• SD-Karten mit maximal 2GB Speicherkapazität
• SDHC-Karten mit maximal 32GB Speicherkapazität
• SDXC-Karten mit maximal 2TB Speicherkapazität (in der Praxis derzeit 128GB)

Die Unterschiede betreffen nicht nur die Speichergröße, sondern auch andere Teile der Spezifikation. Sie können zu unangenehmen Überraschungen führen, wenn man ein Karte eines Typs in einem Gerät nutzen möchte, das dafür nicht ausgelegt ist. Eine Grafik auf dieser Seite der SD Association stellt die Kompatibilitätsanforderungen dar:

SDXC am Jolla

Was bedeutet das konkret fürs Jolla-Phone? Von Jolla wissen wir, daß SD- und SDHC-Karten problemlos funktionieren, SDXC-Karten jedoch nicht. Was Arbeitsauftrag genug ist, ausgerechnet eine SDXC-Karte zu kaufen und herauszufinden, was da dahintersteckt. :)

Ich habe mich für eine Sandisk Ultra SDXC mit 64GB entschieden. Damit sollte ich auskommen, wenn ich bisher mit 16GB zufrieden war. Warum aber mag Jolla die SDXC-Karte nicht? Wenn man sie einlegt, passiert nichts. Sie wird nicht erkannt.

Die Lösung ist gottseidank ausschließlich im Bereich der Software zu finden: Laut Standard müssen SDXC-Karten das Dateisystem exFAT von Microsoft verwenden. Microsoft hat die Spezifikation dafür nie offengelegt, hat es durch Patente vermint und verlangt heftige Lizenzgebühren von Firmen, die es in ihren Produkten verwenden wollen. Heißt für Jolla: Die legale Verwendung von exFAT ist zu teuer, die Verbreitung der existierenden exFAT-Treiber für Linux am Jolla-Handy illegal.

Was aber heißt es für einen Jolla-Benutzer? Zunächst wäre es möglich, exFAT einfach nachzuinstallieren. Ich habe auf den Seiten des Mer-Projekts die Pakete exfat-utils und fuse-exfat für Sailfish OS gefunden, die auch auf meinen anderen GNU/Linux-Systemen für den Zugriff auf exFAT-Partitionen sorgen. Was mich davon abgehalten hat: Es gibt keine Erfahrungsberichte. Zwar gilt fuse-exfat an sich als stabil, aber wer weiß, ob gerade dieses Paket am Jolla Phone ausreichend getestet ist. Ich möchte bei einem Dateisystem möglichst nicht der erste sein, der durch Bugreports zur Weiterentwicklung beiträgt.

Möglichkeit zwei ist, die SDXC-Karte auf ein Dateisystemzu bringen, das der von Jolla verwendete Kernel von Haus aus versteht. Zur Auswahl stehen FAT32, ext4 und btrfs. Btrfs hat mich gerade erst in die Situation gebracht, daß ich eine SD-Karte brauche, also schließe ich es aus. (Obwohl es ziemlich geil wäre: Ich könnte damit Karte und eingebauten Speicher als ein gemeinsames Dateisystem verwalten.) Ext4 ist ein erprobter Standard im GNU/Linux-Umfeld - allerdings nur dort. Für Windows-Systeme, Kameras, MP3-Player und die meisten anderen Geräte wird die Karte mit ext4 unlesbar. Bleibt das gute alte FAT32: steinzeitlich, simpel gestrickt, zu allem kompatibel und gut dokumentiert. Nachteile: Die Dateien dürfen nicht größer als 4GB sein (das werde ich verkraften) und nehmen nicht am Spiel mit den unter GNU/Linux üblichen Benutzerrechten teil (was noch nie gestört hat, seit es FAT-formatierte SD-Karten gibt).

Die Entscheidung ist also gefallen: Ich formatiere die SDXC-Karte neu mit FAT32. Was könnte dabei schon schief gehen?

SD-Karten formatieren ist eine Wissenschaft

Es gibt einen guten Grund, warum in der Regel davon abgeraten wird, Flash-Medien wie SD-Karten von Hand neu zu formatieren. Die Speicherzellen sind in Einheiten mit seltsamen Namen wie „Pages“, „Erase Blocks“ und „Allocation Units“ oder „Erase Block Groups“ zusammengefaßt, die für verschiedene Lese- und Schreiboperationen immer nur gemeinsam angesprochen bzw. verändert werden können. Die Gemeinheit dabei: Auch jedes Dateisystem verwaltet die Daten in größeren Blöcken. Wenn die Blockgrößen nicht zueinander passen, muß der Controller auf der SD-Karte im Extremfall mehrere GB an Daten lesen und zurückschreiben, um eine Textdatei von nur einigen Zeilen zu verändern. Das drückt einerseits auf die Geschwindigkeit, andererseits auf die Lebensdauer des Mediums. Absolutes Ziel: Die Blockgrenzen des Dateisystems sollen auf den von der Hardware vorgegebenen Blockgrenzen liegen und sie keinesfalls überlappen.

Wenn das nur so einfach wäre.

Eine SD-Karte sagt nämlich nicht, wie sie intern organisiert ist. Theoretisch sollte sie dem Standard entsprechend zumindest die Erase Block Size unter /sys/block/mmcblk1/device/preferred_erase_size bekannt geben (mmcblk1 ist hier der Name der Karte, wie er im Verzeichnis /dev aufscheint). Viele Karten tun das entweder gar nicht oder sie lügen dabei und geben fix 4GB an. Eine andere Größe wie die Allocation Unit kann man sich auf Basis der vom Hersteller vorgenommenen Formatierung zusammenreimen. Mit dumpexfat entlocke ich meiner Karte, daß Sandisk das Dateisystem in 128kB-Clusters aufgeteilt hat, was wahrscheinlich ein Hinweis auf die Allocation-Units ist. Ein nutzloser Hinweis allerdings, FAT32 kann so große Einheiten nicht abbilden.

Was also hab ich getan? Zunächst mal hab ich versucht, eine ganz grobe Fehlerquelle auszuschalten: Statt die Karte komplett neu zu partitionieren, hab ich nur den Typ der vorhandenen exFAT-Partition auf „W95 FAT32 (LBA)“ geändert. fdisk -l verrät, daß die Partition irgendwo mitten auf der Karte anfängt und nicht mit dem ersten Sektor. Es wäre also verführerisch, diese Platzverschwendung mit einer Neupartitionierung zu korrigieren. Ich habs bleiben lassen - Sandisk wird sich schon was gedacht haben dabei. (Außerdem hab ich irgendwo gelesen, daß es am Anfang jeder SD-Karte einen „geschützten Bereich“ gibt, wofür auch immer. Das wird er sein.)

Dann hab ich versucht, die Erase Block Size herauszufinden, einen wesentlichen Faktor. Weil die Karte sicherheitshalber gleich gar keine Info ausspuckt, hab ich mich auf das Tool flashbench verlassen, dessen Verwendung eher fortgeschrittener Kaffeesudleserei gleicht und unter anderem hier beschrieben wird. Das Ergebnis war - so hab ich es interpretiert - eine Erase Block Size von stolzen 8GB. Das kann hinkommen: Der leere Bereich am Beginn der Karte umfaßt genau 16GB, endet also an der Grenze eines Erase Blocks. Für alles Folgende gilt also: Niemals mit irgendeiner Einheit des Dateisystems eine 8GB-Grenze kreuzen. Klingt simpel.

War dann auch simpel. Die einzige Einheit, die ich beim Formatieren mit FAT32 noch beeinflussen konnte, war die Clustergröße. Ideal wärs gewesen, hätte ich die 128kB-Cluster der Originalformatierung beibehalten können. Die sind von Sandisk sicher bewußt so gewählt. Leider kann FAT32 aber nur mit Clustergrößen umgehen, die unter 64kB liegen. Egal: Der wesentliche Punkt ist meinem Verständnis nach ja, daß die logischen Einheiten des Dateisystems und die physischen der Karte einander nicht überlappen. Wenn mehrere kleine Blöcke des Dateisystems punktgenau in eine der Verwaltungseinheiten der SD-Karte passen, sollte das zumindest OK sein. Ich hab also einfach ein Viertel der ursprünglichen 128kB-Cluster genommen und FAT32 mit 32kB-Clustern formatiert. Wenn die ursprünglichen 128kB irgendeine Bedeutung hatten, bin ich mit den 32kB zumindest nicht ganz daneben. Und auch die 8GB Erase Blocks lassen sich durch 32kB sauber teilen.

War damit alles erledigt? Nein. Ein FAT32-Dateisystem besteht nicht nur aus Dateiblöcken, sondern auch aus einem Bereich für den File Allocation Table „FAT“, der so etwas wie das Inhaltsverzeichnis darstellt. Dieser FAT steht ganz am Anfang der Partition und schiebt daher alles andere nach hinten. Das würde alles zunichte machen, wenn die Größe des FAT eben gerade nicht ins Schema der Blockgrößen paßt. Um dieses Problem zu lösen, bin ich sehr frei nach diesem Artikel vorgegangen. Der Trick ist, das Dateisystem zweimal zu formatieren. Beim ersten Mal wirft mkfs.vfat die Größe der beiden File Allocation Tables aus, die es angelegt hat. In meinem Fall waren es, soweit ich mich erinnern kann, etwas über 14GB - knapp genug an der nächsten Erase Block Grenze bei 16GB. Ich habe den Parameter -R von mkfs.vfat verwendet, um die FATs genau so weit zu verschieben, daß sie exakt bei 16GB enden und die nachfolgenden Datenblöcke wieder perfekt ausgerichtet sind.

Danke, Android!

Obs das zu 100% richtige Ergebnis ist? Ob ich mich nicht doch irgendwo um 1 Byte verkalkuliert habe? Niemand weiß es. Ich habe kein Tool gefunden, mit dem man die hier geschilderten Zusammenhänge einfach auslesen und visualisieren kann. Die Karte ist nach wie vor schnell (eine minimale Geschwindigkeitseinbuße läßt sich erklären, weil FAT32 einfach nicht so effizient arbeitet wie exFAT). Überraschend für mich war doch, wie viele Leute sich im Internet über genau dieses Problem mit den SDXC-Karten unterhalten. Das können doch nicht alles Jolla-User sein? Bzw.: Wer verwendet denn schon SD-Karten am GNU/Linux Desktop? Des Rätsels Lösung heißt Android: Eine ganze Reihe von Android-Geräten war (und ist?) mit SDXC-Karten genauso überfordert wie mein Jolla-Handy, und die wesentlich größere Nutzerschar hat sich drüben auf der anderen Seite des Zauns bereits um Lösungen umgesehen, die ich nur mehr abschreiben mußte. Gut gemacht! :)