Dieser Anleitung fehlen noch einige Informationen. Wenn Du etwas verbessern kannst, dann editiere den Beitrag, um die Qualität des Wikis noch weiter zu verbessern.
Anmerkung: Anfragen zu Problemen und zu möglichen Lösungen sollten in der zugeordneten Diskussion angefragt und beschrieben werden - ansonsten dieses ist ein ganz normales WIKI - bringe Dich ein!
Das Btrfs-Dateisystem befindet sich noch in der Entwicklungsphase und ist daher nicht für den produktiven Einsatz gedacht. Siehe insbesondere die Hinweise zum Bootloader, zu einem RAID-Verbund sowie gleich lautende Erklärungen der Entwickler.
Ubuntu 12.10 „Quantal Quetzal“
Ubuntu 12.04 „Precise Pangolin“
Ubuntu 11.10 „Oneiric Ocelot“
In diesem Artikel wurde alles Wissenswerte gesammelt, was den Autoren während der Erstellung dieser Artikelserie aufgefallen war und beachtet werden sollte. Diese sind nicht direkt als Anweisung zu verstehen.
Des Weiteren werden in diesem Artikel die von den Benutzern erkannten Probleme und Erkenntnisse zusammengefasst, sofern der Sachverhalt nicht in andere Artikel passt bzw. nicht entsprechende Korrekturen eingebracht werden konnten.
Nachfolgend werden einige Hinweise der Autoren gegeben, die diese während der Erstellung gesammelt haben.
Alle Angaben in dieser Artikelserie orientieren sich am technischen Stand von Precise Pangolin, wurden aber weitestgehend auch unter Oneiric Ocelot ausgetestet. Vorhergehende Versionen (bis einschließlich Natty Narwhal) wurden zwar untersucht - auf eine Beschreibung der Abweichungen jedoch verzichtet. Hier gilt es bei einem geplanten Einsatz des Btrfs-Dateisystems besondere Vorsicht walten zu lassen!
GRUB und GRUB 2 können bis Maverick Meerkat nicht mit einem Btrfs-Dateisystem umgehen. Deshalb sollten Dateisysteme mit einem im Basisverzeichnis integrierten /boot-Verzeichnis bzw. ein separates /boot-Verzeichnis nicht konvertiert werden.
Erst ab Oneiric Ocelot ist es uneingeschränkt möglich, von einem Btrfs-Dateisystem zu booten, jedoch gibt es immer noch 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.
Die Partitionstabellen bei einem Btrfs-Raid-Verbund müssen für alle beteiligten Laufwerke als msdos angelegt sein
Die zur Zeit vom Btrfs-Dateisystem unterstützten Optionen für
die redundanten RAID-Level (raid1 und raid10)
garantieren bei Ausfällen noch keinen ununterbrochene Betrieb, so 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 sehr hilfreich für die Wiederherstellung nach einem Crash. Sie erlauben (sofern wirklich zwei oder mehr physikalische Datenträger eingesetzt wurden) einen defekten Datenträger ohne Datenverlust zu ersetzen.
Eine Installation auf einem Software-RAID, das dann mit einem Btrfs-Dateisystem versehen werden soll, ist nicht möglich. Spätestens nach dem ersten Festplattentest mit dem btrfsck-Befehl führt das zu einem nicht mehr startbaren, irreparablen System!
Während der Erstellungsphase dieser Beschreibung bis zum Release von Precise Pangolin wurden keine gravierenden Fehler entdeckt, noch wurde in dieser Zeit je ein System dauerhaft unbrauchbar, wo die Fehlerursache im Btrfs-Dateisystem zu suchen war. Das ist naturgemäß auch immer abhängig von der verwendeten Hardware und wie man sein System konfiguriert und gepflegt hat.
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.
Hier 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%): [1][2]
sudo btrfs filesystem balance / & sudo cpulimit -p $! -l 20 &
Mit dem &
-Zeichen am Ende der Befehlszeile werden die Befehle als Hintergrundprozesse gestartet.
Es gibt durchaus Ansätze zur Kritik, wenn man bei einem Vergleich der etablierten Dateisysteme mit dem Btrfs-Dateisystem Unterschiede feststellt:
Starten / Bootvorgang / lfd. Betrieb
Hier wurden keine fühlbaren Unterschiede festgestellt, reale Test fielen aber mal so oder so aus. Insbesondere kam hier der Zustand von Upstart nach dem Einspielen von Updates zum Tragen.
Einspielen von Updates
Hier muss man einfach feststellen, dass ein bei gleichem Paketumfang ausgeführtes Update/Upgrade, bei einem Btrfs-Dateisystem erheblich mehr Zeit in Anspruch genommen hat, als auf einem Dateisystem alter Art. Selbst sogenannte Tricks und Insider-Maßnahmen helfen nicht darüber hinweg. Als hilfeich hat sich ein Eintrag in der /etc/fstab erwiesen:
1 | tmpfs /var/cache/apt/archives tmpfs size=15%,defaults 0 0 |
Dieses ist natürlich stark davon abhängig, wieviel RAM man zur Verfügung hat.
Festplattenprüfung
Die Festplattenprüfung endet zur Zeit nur mit der Feststellung, ob das Dateisystem in Ordnung ist bzw. Fehler enthält. Eine Fehlerkorrektur findet nicht statt!
Es wird deshalb empfohlen, diese obligatorische Überprüfung beim Hochfahren in der /etc/fstab abzuwählen und diese Überprüfung regelmäßig im Terminal manuell auszuführen.
Insbesondere kann man eine Mehrfachprüfung vermeiden, indem man auf einer Partition bei gemeinsam abgelegten Unterlaufwerken (Subvolumes - @ und @home und ggf. weitere) zumindest das zweite (und auch weitere) Unterlaufwerk abwählt.
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
mit apturl
Paketliste zum Kopieren:
sudo apt-get install apt-btrfs-snapshot
sudo aptitude install apt-btrfs-snapshot
verwenden. Allerdings wurden dabei Probleme wie hohe CPU-Auslastung bis hin zum Einfrieren des Systems beobachtet, sodass die oben beschriebene Methode vorzuziehen ist.
Alle Beschreibungen basieren auf den
btrfs-tools
mit apturl
Paketliste zum Kopieren:
sudo apt-get install btrfs-tools
sudo aptitude install btrfs-tools
der Version 0.19 von 2010, die in einer Standardinstallation bereits vorhanden sind. Für ältere Ubuntu-Versionen (bis Natty Narwhal) sollte man das nur zur Information anwenden.
Um den aktuellen Befehlsumfang zu den einzelnen Befehlen btrfs
zu erhalten (Optionen, Ergänzungen), sollte man den jeweiligen Befehl im Terminal [1] ohne Option (entspricht der Option --help
) abfragen - die Manpages sind teilweise fehlerhaft bzw. es fehlen Hinweise ganz!
Wer sein System optimal betreuen will, sollte auf das aktuelle Paket btrfs-tools zurückgreifen, das ab Precise Pangolin problemlos installiert und eingesetzt werden kann. Mit diesem Paket ist nun u.a. eine, wenn auch noch eingeschränkte Reparatur des Filsystemes mit dem Befehl
btrfsck
sowie eine erweiterte Prüfung mittels dem scrub
-Befehl möglich.
Als wichtiges Werkzeug für die Bearbeitung und auch zur Datenrettung wird das Anlegen eines USB-Sticks mit der Architektur des Basissystems (i386 / x86_64) z.B. mit einer
ab Version Oneiric Ocelot bzw. mit dem Tool
(in einer Version ab Nov. 2011 PartedMagic) empfohlen, beide Betriebssysteme beinhalten das Paket btrfs-tools in Version 0.19 (Stand 2010) als Standardausstattung.