Bitrot schummelt Fehler leise ins Dateisystem

Unter Bitrot bezeichnet man umgangssprachlich das „Kippen“ einzelner Datenbits. Dies kann etwa bei Zahlen schnell dramatische Folgen hervorrufen: Habt ihr etwa 100 Euro auf dem Konto (Binär: 1100100) und das erste Bit kippt in der Datenbank der Bank zu einer 0, dann schrumpft euer Guthaben auf einen Schlag auf nur noch 36 Euro (Binär: 0100100). Damit dies nicht passiert, speichern moderne Dateisysteme Daten redundant und schreiben Prüfsummen, sodass man zum einen merkt, dass etwas mit den Daten nicht stimmt und zum anderen sie auch automatisch wiederherstellen kann. Auch Dateiformate selber besitzen eine gewisse Redundanz, sodass kleine Datenfehler im Bild eigentlich kaum ersichtlich sein sollten. Daher hat mich dieser Beitrag von Ars Technica sehr gewundert. Schon nach drei gekippten Bits ist das dort gezeigte Bild nicht mehr erkennbar. Gut, nach 10 gekippten Bits bin ich auch nicht mehr wiederzuerkennen, aber der Totalausfall nach 3 gedrehten Bits macht einem schon Sorgen — schließlich gehören Bilder für viele von uns zum wertvollsten Datenschatz.

Um das Thema also einmal selber nachzustellen, braucht es ein Bild und ein kleines Programm, mit dem man gezielt einzelne Bits einer Datei umkippen lassen kann. Im Netz finden sich dazu eine Reihe von kleinen Code-Schnippseln, der folgende in Python geschriebene Code macht als bitflip.py abgespeichert genau dies. Als Parameter übergebt ihr dem Programm einen Offsetwert, also im Endeffekt das wievielte Bit es drehen soll. Zudem habe ich mit bitflip.sh ein kleines Shell-Skript geschrieben, das automatisiert eine beliebige Anzahl an Bits einer Datei drehen kann. Es nummeriert zudem die einzelnen Bilder und erstellt am Ende aus den Einzelbildern ein Video — mit dem Ziel am Ende den Verfall des Bildes als animierten Verlauf zu sehen.

Skripte zum automatisierten Drehen einzelner Bits

bitflip.ph

#!/usr/bin/python
"""Toggle the bit at the specified offset.
Syntax:  filename bit-offset"""

import sys
fname = sys.argv[1]
# Convert bit offset to bytes + leftover bits
bitpos = int(sys.argv[2])
nbytes, nbits = divmod(bitpos, 8)

# Open in read+write, binary mode; read 1 byte 
fp = open(fname, "r+b")
fp.seek(nbytes, 0)
c = fp.read(1)

# Toggle bit at byte position `nbits`
toggled = bytes( [ ord(c)^(1<<nbits) ] ) 
# print(toggled) # diagnostic output

# Back up one byte, write out the modified byte
fp.seek(-1, 1)  # or absolute: fp.seek(nbytes, 0)
fp.write(toggled)
fp.close()

bitflip.sh

#!/bin/bash
# Settings
ORIGFILE=$1
FIRSTBIT=$2
LASTBIT=$3
STEPWIDTH=$4

# Folders
FLIPPEDFILES=tmp_flipped
VIDEOTEMP=tmp_video

# Init
FLIPPEDBITS=0

# Watch for Ctrl+C
trap "exit" INT

# Prepare
if [[ ! -e $FLIPPEDFILES ]]; then
	mkdir $FLIPPEDFILES
else
	rm $FLIPPEDFILES/*
fi

if [[ ! -e $VIDEOTEMP ]]; then
	mkdir $VIDEOTEMP
else
	rm $VIDEOTEMP/*
fi

# Function annotate
function annotate () {
	convert $1/$2.jpg -gravity southeast \
		-stroke '#000C' -pointsize 100   -strokewidth 2 -annotate 0 $3 \
		-stroke  none   -pointsize 100   -fill white    -annotate 0 $3 \
		$1/$2.jpg
}

# Flip bits
cp $ORIGFILE $FLIPPEDFILES/$FIRSTBIT.jpg
convert $ORIGFILE $FLIPPEDFILES/$FIRSTBIT.jpg +append $VIDEOTEMP/$FIRSTBIT.jpg

while [  $FIRSTBIT -lt $LASTBIT ]; do

	echo Flipping bit: $FIRSTBIT
	echo Flipped bits: $FLIPPEDBITS

	let PLUSONE=FIRSTBIT+STEPWIDTH
	cp $FLIPPEDFILES/$FIRSTBIT.jpg $FLIPPEDFILES/$PLUSONE.jpg
	./bitflip.py $FLIPPEDFILES/$PLUSONE.jpg $PLUSONE
	convert $FLIPPEDFILES/$FIRSTBIT.jpg $FLIPPEDFILES/$PLUSONE.jpg +append $VIDEOTEMP/$PLUSONE.jpg
	annotate $VIDEOTEMP $PLUSONE $FLIPPEDBITS

	let FIRSTBIT=FIRSTBIT+STEPWIDTH
	let FLIPPEDBITS=FLIPPEDBITS+1
	clear
done

# Build video
cd $VIDEOTEMP
cat *.jpg | ffmpeg -y -f image2pipe -r 15 -vcodec mjpeg -i - -vcodec libx264 ../out.mp4

Doch bevor ich das Skript auf ein JPG loslasse, muss bitflip.py beweisen, ob es auch wirklich funktioniert. Dazu nehme ich ein beliebiges PNG-Bild und flippe gezielt ein einzelnes Bit. Ein binärer Vergleich mit cmp zeigt dann den Unterschied. Der Aufruf von file erkennt anschließend zwar noch eine PNG-Datei, doch ein Bildbetrachter mag die Datei nicht mehr öffnen, wie auch identify aus der Imagemagick-Suite mit IDAT: CRC error einen Fehler in der Bilddatei meldet. Schalte ich das Bit erneut um, dann akzeptiert identify das Bild wieder brav und der Bildbetrachter von Gnome öffnet die PNG-Datei ebenfalls wieder. Sum­ma sum­ma­rum: Schon ein gekipptes Bit kann eine Datei komplett ruinieren. JPG bringt jedoch deutlich mehr Redundanzen mit, von daher bin ich gespannt, wie sich das für Fotografien übliche Dateiformat schlägt.

### Beliebige PNG-Datei kopieren
$ cp picture.png picture-flip.png
### Als Beispiel das 2000. Bit flippen
$ ./bitflip.py picture-flip.png 2000
### Hat es geklappt, ja!
$ cmp -l picture.png picture-flip.png | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
000000FB 1C 1D

### Immer noch eine PNG-Datei?
$ file picture-flip.png
picture-flip.png: PNG image data, 800 x 533, 8-bit/color RGB, non-interlaced
### Bild-Information kaputt
$ identify -verbose picture-flip.png
identify: IDAT: CRC error `picture-flip.png' @ error/png.c/MagickPNGErrorHandler/1630.
identify: corrupt image `picture-flip.png' @ error/png.c/ReadPNGImage/3959.

### Gegenprüfung, wieder das 2000. Bit flippen
$ ./bitflip.py picture-flip.png 2000
### Bild-Informationen stimmen wieder
$ identify -verbose picture-flip.png
Image: picture-flip.png
  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 800x533+0+0
  Resolution: 28.35x28.35

Bei Ars schildert Autor Jim Salter nun, dass schon mit einem geflippten Bit im JPG-Bild Artefakte erscheinen. Nach zwei und erst recht nach drei gekippten Bits ist dann kaum mehr etwas von dem Originalbild zu erkennen. In meinen Tests kann ich das nun aber nicht nachvollziehen: Mein Testbild bleibt ein Bild und für das Auge ergibt sich kein erkennbarer Unterschied, nur cmp meldet (wie gewünscht) die Anzahl der Unterschiede in den jeweiligen Dateien. Ich habe den Vergleich bewusst auf eine „richtige“ Fotografie beschränkt und nicht auf eine künstlich kleine JPG-Datei, da natürlich die Redundanz mit der Größe des Bildes zunimmt. 1000 gekippte Bits in einer 1 Kb großen Datei dürften sich deutlich dramatischer auswirken als in einer 5 Mb großen Datei, frisch von der Digitalkamera geladen.

Mit 10 gekippten Bits

$ cmp -l ../katze_orig.jpg 11000.jpg | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}' | wc -l
10

Mit 100 gekippten Bits

$ cmp -l ../katze_orig.jpg 20100.jpg | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}' | wc -l
100

Mit knapp 1000 gekippten Bits

$ cmp -l ../katze_orig.jpg 110000.jpg | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}' | wc -l
999

Lange Rede, kurzer Sinn: Ganz so schlimm, wie es der Autor von Ars darstellt, wirkt sich Bitrot bei JPEG-Dateien nicht aus. Dennoch sollte man sich bei seiner Backupstrategie ein wenig Gedanken an die Tatsache verschwenden, dass einzelne Bits auf dem Datenträger kippen können. Sichert man nun einfach nur stumpf seine Daten auf ein Backup-Medium, dann wandert der Defekt unbemerkt ins Backup und ersetzt auch irgendwann mal die älteste Version in der Sicherung, sodass eine Wiederherstellung zu einem späteren Zeitpunkt unmöglich wird. Dazu gehören moderne Dateisysteme wie Btrfs oder ZFS, die Prüfsummen für alle Daten anlegen (nicht nur wie Ext4 für das Journal) und am besten darunter noch ein RAID1, sodass man Daten leicht wiederherstellen kann.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Solltet Ihr PressFS einmal austesten wollen, so würde ich euch empfehlen, dies nicht gerade mit eurer „richtigen“ WordPress-Installation zu tun. Das Projekt steckt in den Kinderschuhen, zwar kann man bislang nichts verändern, doch sicher ist sicher… Um nun PressFS zu probieren, müsst ihr den Code bei GitHub auschecken, des Weiteren braucht ihr für den Betrieb auch noch die Python-Bindings für Fuse.

$ sudo apt-get install python-fuse git
$ git clone https://github.com/josephscott/pressfs.git

Sobald Ihr den Code habt, geht ihr in das heruntergeladene Verzeichnis mit dem Code und erzeugt euch eine Konfigurationsdatei config.ini aus der mitgelieferten Vorlage, öffnet diese danach gleich in eurem Lieblingseditor.

$ cp example-config.ini config.ini
$ gedit config.ini

In der Datei müsst Ihr nun eure Zugangsdaten und die URL zum Blog eintragen. Beachtet, dass die Authentifizierung über HTTP erfolgt und die Zugangsdaten somit im Klartext übertragen werden. Besser wäre es – so man denn ein SSL-Zertifikat hat – SSL zu verwenden.

url = http://urlzueuremblog.de/wordpress
username = Ichbineinadmin
password = ganzgeheim

[Cache]
req_expire = 3

Somit ist die Konfiguration auf eurem Rechner abgeschlossen. Als Nächstes muss das mitgelieferte WordPress-Plugin ins Blog geladen und aktiviert werden. Der Vorgang unterscheidet sich überhaupt nicht von der Installation üblicher Plugins.

Jetzt könnt ihr euer WordPress-Blog mounten. Erzeugt einen Mount-Punkt, bspw. /var/wordpress, und führt dann das pressfs.py-Skript aus. Wenn Ihr danach im Terminal oder mit einem Dateimanager nach /var/wordpress geht, dann solltet ihr euer Blog „sehen“.

$ sudo mkdir /var/wordpress
$ python pressfs.py /var/wordpress

Die Inhalte des Blogs werden über verschiedene Unterverzeichnisse wiedergegeben. Für Kategorien, Beiträge, Schlagwörter und Benutzer wird jeweils ein Verzeichnis angelegt, das die entsprechenden Inhalte wiederum als Datei beinhaltet.

• /var/wordress/categories/
• /var/wordpress/posts/
• /var/wordpress/tags/
• /var/wordpress/users/

Die Verzeichnisse und die Dateien könnt Ihr im Dateimanager bzw. in jedem beliebigen Programm öffnen. So könnt Ihr bspw. einen Beitrag in Gedit öffnen und dort – wenn denn das Schreiben einmal möglich wird – bearbeiten und wieder abspeichern.

Wenn Scott es schafft Schreibvorgänge sicher zu implementieren, dann wird PressFS für Linux-Blogger sicher eine feine Sache. Ich kann mir zwar nicht vorstellen, damit das Web-Backend von WordPress überflüssig zu machen, aber wenn man schnell bestehende Beiträge verändern, oder per grep, sed und Co. automatisiert Inhalte ändern möchte… dann kann PressFS vielleicht ganz praktisch werden.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Warum? Das Dateisystem hat sich unter Solaris schon seit Jahren bewährt und hat Features, die es auch für den Desktop interessant machen. Deduplizierung, Snapshots, etc. Weiteres lässt sich in der Wikipedia nachlesen. Besonders die eingebaute Möglichkeit gelöschte Daten oder ältere Dateistände wiederherzustellen, ist schick, ich bin gespannt wann die von Sun an Nautilus erstellten Patches auch unter Linux Einzug halten.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Das Einheiten-Chaos

Der primäre Unterschied liegt in der unterschiedlichen Rechenweise von Festplattenherstellern und Informatikern. In der „normalen“ Welt sind wir die 10 als Vorsatz für Maßeinheiten gewohnt. Bei den Gewichtseinheiten wird immer mit 10 hoch irgendwas gerechnet, also beispielsweise…

• 1 Kilogramm sind 10^3 Gramm
• 1 Tonne sind 10^3 Kilogramm oder 10^6 Gramm
• usw…

Informatiker rechnen nun meist binär. Daher verwenden sie die 2 als Präfix für Potenzen.

• 1 Byte entspricht 8 Bit
• 1 Kilobyte sind 2^10 Byte, also 1024 Byte
• 1 Megabyte sind 2^20 Byte, also 1.048.576 Byte
• usw…

Bei den auf der 2 basierenden Einheiten sollte man daher eigentlich von Kibibyte, Mebibyte und Co. reden, doch im allgemeinen Sprachgebrauch macht das praktisch niemand. Die Folge dieser unterschiedlichen Rechenweise: Eine vom Hersteller mit 1000 GByte Speicherkapazität angegebene Festplatte wird vom Betriebssystem mit nur rund 932 GByte ausgewiesen.

Den Marketing- und Kaufleuten der Festplattenhersteller kommt die größer aussehende Auszeichnung natürlich besser, als die „kleinere“ Rechenweise der Informatiker. Viel mehr will ich gar nicht auf diesen Unterschied eingehen. In der Wikipedia und selbst auf Spiegel Online finden sich wirklich gute Artikel, die das Thema auch dem Laien und Nichtmathematiker erklären…

Ext2, Ext3 und Ext4 reservieren Speicher

Das eigentliche Thema ist die Tatsache, dass bei der Formatierung einer Festplatte mit Ext2 oder Ext3 (Ext4 scheint auch noch zu machen, allerdings scheitert tune2fs bei Ext4) als Dateisystem ein Teil der Festplatte für das System reserviert wird. Zum Warum und Weshalb komme ich gleich, erst einmal kurz ein paar Zahlen… Ich demonstriere das an einer alten Festplatte mit vom Hersteller angegebenen 4,32 GByte. Schaut man sich die Ausgabe von df -h an, so sieht man dass von den real freien 4GB Speicherplatz nur 3,7 GByte verfügbar sind

$ df -h
Dateisystem Größe Benut Verf Ben% Eingehängt auf
[...]
/dev/sdh1 4,0G 137M 3,7G 4% /media/disk-1

Der Grund dafür liegt darin, dass bei Ext{2,3,4} als Dateisystem von Haus aus 5% des Speicherplatzes einer Partition für das System reserviert werden. Dies soll Fragmentierung verhindern und garantieren, dass wichtige Dienste IMMER schreiben können, selbst wenn ein User des Systems die Platte zugemüllt hat. Die man-Page von tune2fs beschreibt die Funktion so…

$ man tune2fs
[...]
-m reserved-blocks-percentage

Set the percentage of the filesystem which may only be allocated by privileged processes. Reserving some number of filesystem blocks for use by privileged processes is done to avoid filesystem fragmentation, and to allow system daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the filesystem. Normally, the default percentage of reserved blocks is 5%.

Bei modernen Platten ist dieser reservierte Speicherbereich mit 5% natürlich recht groß, bei einer Platte mit 1000 GB werden zum Beispiel 50GB reserviert. Gerade wenn man eine Festplatte nur als Datenspeicher benutzt, kann man diesen Wert ruhig runtersetzen. Über den Befehl…

$ sudo tune2fs -m [Prozentsatz] /dev/sd[xy]

kann man dies über ein Terminal machen. Die Partition kann währenddessen eingehängt (aka gemountet) bleiben. Den Prozentsatz könnt Ihr dabei frei wählen. Die Partition muss man natürlich korrekt angeben, Ihr findet die Partition etwa über fdisk heraus…

$ sudo fdisk -l
[...]
Platte /dev/sdh: 4327 MByte, 4327464960 Byte
255 Köpfe, 63 Sektoren/Spuren, 526 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x16b6ac7b

Gerät boot. Anfang Ende Blöcke Id System
/dev/sdh1 1 526 4225094+ 83 Linux

Habt Ihr eine Partition nur mit Daten, so könnt Ihr den reservierten Speicherplatz komplett deaktivieren. Nach einem…

$ sudo tune2fs -m 0 /dev/sdh1
Setze den Prozentsatz reservierter Böcke auf 0% (0 Blöcke)

…steht auf der vorhin gezeigten Festplatte nun (fast) der komplette Speicherplatz auch zur Verfügung.

$ df -h
[...]
/dev/sdh1 4,0G 137M 3,9G 4% /media/disk-1

Die bereits nach der Formatierung belegten MB dienen dem Journal des Ext4-Dateisystems. „Ganz leer“ bekommt Ihr die Platte mit Ext4 also nie.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Was recht eigenartig ist, dass das Programm ein paar Minuten lang behauptet, dass es in wenigen Sekunden fertig sei und dass man auf keinen Fall den Vorgang unterbrechen sollte.

Nun gut, ich hab brav gewartet und nach ein paar Minuten war der Stick dann auch formatiert. Nicht schön ist, dass der Windows Explorer diesen Vorgang nicht so toll findet und sich nach dem Formatieren des Sticks aufhängt, aber was soll ich auf einem Linux-Blog über Windows lästern Richtig nett ist auch, dass Windows mich den Stick nicht mit NTFS formatieren lässt… Aber wozu hat man gparted.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

UPDATE: Leser dieses Artikels sollten bedenken, dass sich das Rad der Geschichte immer weiterdreht. Zum Zeitpunkt der Erstellung des Beitrages waren diese Informationen korrekt, doch mittlerweile kann man beruhigt zu Ext4 greifen. Die im Beitrag genannten Patches haben es sogar noch in den Kernel von Ubuntu Jaunty geschafft. Ext4 IST in der Zwischenzeit reif für den Desktop geworden!

I recently installed Kubuntu Jaunty on a new drive, using Ext4 for all my data.

The first time i had this problem was a few days ago when after a power loss ktimetracker’s config file was replaced by a 0 byte version . No idea if anything else was affected.. I just noticed ktimetracker right away.

Today, I was experimenting with some BIOS settings that made the system crash right after loading the desktop. After a clean reboot pretty much any file written to by any application (during the previous boot) was 0 bytes. For example Plasma and some of the KDE core config files were reset. Also some of my MySQL databases were killed…

Es ist auch kein „Ubuntu-Problem“

I thought it was worth adding this, even though I’m running Gentoo, it seems to be exactly the same issue:

I recently upgraded to ext4 as well, I ran a game in Wine and the system hardlocked (nothing special there with the fglrx drivers). After rebooting all my Wine registry files were 0 bytes, as were many of my Gnome configuration files. Absoloute nightmare. fsck on boot said that it had removed 760+ orphaned inodes.

Um es kurz zusammenzufassen: Sollte ein Rechner mit Ext4 Partitionen abstürzen oder ihm der Saft ausgehen, so droht massiver Datenverlust. Die Gefahr bei einem Crash Daten zu verlieren ist deutlich höher als bei Ext3. Das Problem ist massiv und bedarf sowohl Änderungen am Kernel wie auch Änderungen an der Art und Weise wie Anwendungen Daten ablegen. Theodore Ts’o – einer der bekanntesten Entwickler des Linux-Kernels – fasst das Problem hier sehr gut zusammen.

Ext4 mag reif für Serversysteme sein, denen dank USV sicherlich nie der Strom ausgeht. Doch man sollte es sich mehr als zweimal überlegen Ext4 auf einem Notebook oder Desktop einzusetzen, denen dank proprietärer Treiber und experimentierfreudiger User der eine oder andere Absturz droht!

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.