Bootloader¶

Es ist zwar uneingeschränkt möglich, von einem Btrfs-Dateisystem zu booten, jedoch gibt es Probleme mit GRUB 2-Funktionen, die ein Schreiben auf den Datenträger erfordern. Siehe dazu u.a. die Hinweise unter

• Schreiben auf GRUB_2 bei LVM, RAID und Btrfs

• nach einer Btrfs-Installation GRUB 2 einrichten

Des Weiteren kann GRUB 2 die …/grub.cfg beim Booten nicht auslesen, wenn bei der Mountoption compress für die Komprimierung anstelle der Standardeinstellung zlib eine Komprimierung mit lzo verwendet wird.

RAID-Verbund¶

Die zur Zeit vom Btrfs-Dateisystem unterstützten Optionen für

• die redundanten RAID-Level 1, 5, 6, 10, single oder dup und

• das nicht-redundante RAID-Level 0

garantieren bei Ausfällen noch keinen ununterbrochenen Betrieb, wie es ein redundantes Software-RAID auf zwei oder mehr physikalisch vorhandenen Festplatten bietet. Bei einem Ausfall einer Festplatte bzw. Partition läuft das System möglicherweise nicht mehr weiter.

Dennoch sind diese RAID-Level in Bezug auf die Daten und Metadaten sehr hilfreich für die Wiederherstellung nach einem Crash. Sie erlauben es, sofern wirklich zwei oder mehr physikalische Datenträger eingesetzt wurden, einen defekten Datenträger eingeschränkt (degraded) zu starten, zu mounten sowie ohne Datenverlust zu ersetzen.

Die Installation auf einem Software-RAID (zwei oder mehr physikalische Festplatten) mit einer Btrfs-Dateisystem Formatierung zu versehen ist möglich und unterstützt die Datensicherheit in weiteren Ebenen.

Aktuelle Betriebssicherheit¶

Während der Erstellungsphase dieser Beschreibung bis zur Freigabe von Ubuntu 12.04 wurden keine gravierenden Fehler entdeckt, noch wurde je ein System dauerhaft unbrauchbar. Das ist naturgemäß auch immer abhängig von der verwendeten Hardware und wie man ein System konfiguriert und pflegt.

Prozessorbelastung¶

Einige Btrfs-Befehle beanspruchen das System bis an die Grenzen, so dass ein vernünftiges paralleles Weiterarbeiten zwar (eingeschränkt) möglich ist, ohne dass es zu Konflikten mit den Daten kommt, jedoch kann es stören. Hier hilft der Einsatz des Zusatzbefehls nice bzw. cpulimit.

• Ein Beispiel mit nice, das dem Btrfs-Befehl eine niedrigere Priorität gibt ^[1][2]:

  sudo nice -n 15 btrfs filesystem balance / & 

• Alternativ mit cpulimit, dass die Prozessorauslastung durch den Befehl beschränkt (hier: auf 20 %):

  sudo btrfs filesystem balance / & sudo cpulimit -p $! -l 20 & 

Mit dem &-Zeichen am Ende der Befehlszeile werden die Befehle als Hintergrundprozesse gestartet.

Geschwindigkeiten¶

tmpfs  /var/cache/apt/archives   tmpfs   size=15%,defaults  0  0

Backup und Replay¶

Dieses ist ein besonders positiv zu bewertender Punkt für das Btrfs-Dateisystem - vorausgesetzt, es werden bestimmte Grundregeln eingehalten und beachtet. Durch den regelmäßigen Einsatz von sogenannten Schnappschüssen kann man jederzeit auf einen Zustand zum Zeitpunkt der Erstellung des Schnappschusses zurücksetzen, falls man mal eine falsche Konfiguration gewählt hatte oder das System durch überflüssige Pakete nicht mehr optimal läuft.

Nach der Prüfung, ob eingespielte Updates auch lauffähig sind, kann man dann einen vorhergehenden Schnappschuss löschen und durch einen neu erstellten ersetzen. Dafür kann man das folgende Skript als Anregung nehmen und seinen Bedürfnissen angepasst, z.B. als cron-snapshot lauffähig nach (alternativ)

• /etc/cron.daily

• /etc/cron.weekly

ablegen - dieses Skript übernimmt dann im aktiven Rechner periodisch diese Aufgabe:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/bin/sh -e

snap_root () {
[ -d /mnt/r$datum ] && return
[ -d /mnt/r* ] && btrfs sub del /mnt/r* >/dev/null
btrfs sub snap /mnt/@ /mnt/r$datum >/dev/null
echo "snapshot r$datum angelegt" >> /home/.snapshot.log
}

snap_home () {
[ -d /mnt/h$datum ] && return
[ -d /mnt/h* ] && btrfs sub del /mnt/h* >/dev/null
btrfs sub snap /mnt/@home /mnt/h$datum >/dev/null
echo "snapshot h$datum angelegt" >> /home/.snapshot.log
}

file_system=btrfs
root_device=$(sed -n "/\/ $file_system /s|^\(.*\) / $file_system .*|\1|p" /proc/mounts)
root_uuid=$(blkid -t TYPE=$file_system -o value -s UUID "$root_device") >/dev/null
[ "x$root_uuid" = "x" ] && exit # kein passendes Btrfs gefunden

datum=$(date "+%Y-%W") # für wöchentlich, alternativ für monatlich -> "+%Y-%m"
[ `tail -n 1 /home/.snapshot.log | cut -d ' ' -f 2` = "r$datum" ] && exit; # Eintrag ist schon aktuell

echo "Überprüfung am `date +%d.%m.%Y`:" > /home/.snapshot.log
mount -o compress "UUID=$root_uuid" /mnt >/dev/null
[ -d /mnt/@ ] && snap_root
[ -d /mnt/@home ] && snap_home
umount /mnt

Alternativ kann man auch das Paket apt-btrfs-snapshot verwenden. Allerdings wurden dabei Probleme wie hohe CPU-Auslastung bis hin zum Einfrieren des Systems beobachtet, sodass die oben beschriebene Methode über ein geeignetes Skript vorzuziehen ist.

Empfohlene Maßnahmen¶

Alle Beschreibungen basieren auf dem Paket btrfs-tools in der Version 0.19 oder neuer, die in einer Standardinstallation ab Ubuntu 12.04 bereits enthalten sind. Mit diesem Paket ist u.a. eine Reparatur des Filesystemes mit dem Befehl btrfsck sowie eine erweiterte Prüfung mittels des scrub-Befehls möglich.

Um den aktuellen Befehlsumfang zu den einzelnen Befehlen zu erhalten (Optionen, Ergänzungen), sollte man den jeweiligen Befehl im Terminal^[1] ohne Option (entspricht der Option --help) abfragen - die Manpages waren in der Vergangenheit teilweise fehlerhaft bzw. es fehlen Hinweise ganz!

Intern¶

• Das Btrfs Dateisystem

  • Installieren auf Btrfs-Dateisystem

  • Konvertierung nach Btrfs

  • Befehle Btrfs-Dateisystem

  • Btrfs-Mountoptionen

Extern¶

• Btrfs-Dateisystem

• Ubuntu-Help Btrfs

• btrfs.wiki.kernel.org

• Btrfs im Detail - Admin-Magazin, 04/2009

• funtoo.org Btrfs