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 gewundet. 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.ph abgespeichert genau dies. Als Parameter übergebt ihr den Programm einen Offsetwert, also im Endeffekt das wie vielte 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.ph beweisen, ob es auch wirklich funktioniert. Dazu nehme ich ein beliebiges PNG-Bild und flippe gezielt ein einzelnes Bit. Ein binärer Verglich 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 einen 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 runinieren. 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 es 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 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, die Prüfsummen wie Btrfs oder ZFS 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.

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.

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 gerecht, 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 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.

Dem Marketing- und Kaufleuten der Festplattenherstellern 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 nicht-Mathematiker 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% 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 kann Ihr dabei frei wählen. Die Partition muss man natürlich korrekt angegeben, 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 gezeigte 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-Dateisystem. „Ganz leer“ bekommt Ihr die Platte mit Ext4 also nie.

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ären Treiber und experimentierfreudigen Usern der eine oder andere Absturz droht!