Fryboyter

Dateisystem Btrfs wird demnächst Swap-Dateien unterstützen

Seit Jahren verwende ich auf meinen privaten Rechnern kein Swap. Für spezielle Fälle war es aber ganz nützlich mal eben eine Swap-Datei anzulegen. Seit ich Btrfs nutze, war dies leider keine Option mehr, da dieses Dateisytem keine Swap-Dateien unterstützt. Das wird sich demnächst voraussichtlich aber wieder ändern.

Warum wieder? Im Jahre 2009 wurde die Unterstützung von Swap-Dateien entfernt, da Swap-Dateien Probleme gemacht haben. Der Entwickler Omar Sandoval hat nun aber kürzlich einen Patcheingereicht, der die sichere Nutzung von Swap-Files unter Btrfs ermöglicht. Wenn es keine Probleme damit gibt, könnte diese Änderung bereits in der übernächsten Version des Kernels (voraussichtlich März 2019)_enthalten sein.

Linux | OSBN

Btrfs-Treiber für Windows

Um unter Windows auf Partitionen mit dem Dateisystem ext3/4 zugreifen zu können gibt es Tools wie den Linux Reader von Diskinternal. Für Partitionen mit dem Dateisystem Btrfs ist mir noch kein funktionierendes Programm untergekommen. Wenn man also, wie ich, Btrfs nutzt und unter Windows mal eben auf die Linux-Partitionen zugreifen will ist das blöd. Die Situation könnte sich nun eventuell ändern.

Der Nutzer maharmstone hat auf Github eine erste Version von WinBtrfs veröffentlicht. Laut dem Entwickler ist ein Lese- und Schreibzugriff bereits möglich. Sachen wie RAID oder LZO-Komprimierung werden allerdings derzeit noch nicht unterstützt. Das ganze ist als erste Alpha-Version gekennzeichnet. Von einem produktiven Einsatz sollte man derzeit somit noch absehen. Feedback ist laut maharmstone willkommen. Egal ob positiv oder negativ.

Linux | OSBN

Achtung beim Klonen einer Btrfs-Partition

Da ich zu Weihnachten eine SSD bekommen habe, habe ich die Partitionen meiner Linux-HDD kurzerhand auf die SSD geklont. Da ich solchen Vorgängen nicht 100%ig vertraue wollte ich die normale Festplatte erst einmal ohne Änderungen im System belassen. Quasi als Backup. Nachdem ich im UEFI die Bootreihenfolge umgestellt hatte, konnte ich auch wunderbar von der SSD booten. Allerdings war das Ganze nicht schneller als per HDD und eine der HDD hatte dabei auch Schreib- bzw. Lesezugriffe.

Hmmm… der Groschen ist recht schnell gefallen. Ich mounte über die UUID der Partitionen. So kann ich eine SATA-Platte abklemmen und auf einen anderen SATA-Port anschließen und der Rechner bootet weiterhin, da sich die UUID nicht ändert. Auch beim Klonen nicht. Somit hatte ich auf der SSD als auch der HDD die gleichen UUID und die wurden beide gnadenlos gemountet. Zweimal /, zweimal /boot und zweimal /home. Das es dabei nichts zerrissen hat, war vermutlich Glück. Beim letzten Festplatten-Umzug habe ich mittels tune2fs /dev/sdXY -U urandom einfach neue UUID vergeben (anstelle von sdXY sollte man natürlich die Partitionen der alten Platte angeben). Wie schon angemerkt habe ich eigentlich drei Partitionen. Einmal /boot, einmal / und einmal /home. Boot habe ich, da dort nichts wichtiges liegt, kurzerhand von der alten Platte getilgt. Home (ext4) konnte ich mit genanntem Befehl eine neue UUID verpassen. Nur / hat sich standhaft geweigert. Dort setze ich Btrfs als Dateisystem ein. Tune2fs ist aber nur für ext2 bis ext4. Aber es gibt ja btrfstune. Hier gibt es allerdings keine Möglichkeit die UUID zu ändern. Herzlichen Glückwunsch, das ist bei Btrfs auch nicht vorgesehen.

Wer also auf die Idee kommt, eine Btrfs-Partition zu klonen und beide Partition hinterher mounten zu wollen, sollte hier lieber dann bei einer der beiden Partitionen auf /dev/sdXY oder das Label der Partition zurückgreifen und nicht auf die UUID. Nur so als kleiner Hinweis am Rande.

Linux | OSBN

Btrfs - Eine erste Zwischenbilanz

Vor etwas mehr als einen Monat habe ich meine Root-Partition nun auf Btrfs umgestellt. In dieser Zeit hatte ich mehrere größere Updates meiner Distribution eingespielt und auch zwei mal das System zu Absturz gebracht. Einmal durch ein Programm eines Bekannten, dass ich testen sollte und einmal dadurch, dass ich in der Steckdosenleiste leider den falschen Stecker gezogen habe.

Wirklich interessiert hat es aber mein System nicht. Es funktioniert alles wie es soll. Da es auch keine anderen Probleme gibt und ich z. B. die Snapshot-Funktion immer mehr mag, habe ich nun mittels folgender Befehle das Image der ext4-Partition, dass beim Umwandeln auf btrfs automatisch angelegt wurde, nun endgültig entfernt.

rm /ext2_saved/*
nbtrfs subvolume delete /ext2_saved

Derzeit kann ich also das neue Dateisystem, soweit man das nach einem Monat machen kann, nur empfehlen. Zumindest für private Rechner.

Zwischenzeitlich wurde ich auch schon gefragt, ob ich eventuell Benchmarks machen könnte. Ja, ich könnte. Ich werde es allerdings nicht machen. Mir geht es dabei nicht darum, ein noch schnelleres Dateisystem zu verwenden. Mir geht es hauptsächlich um die Funktionen wie Snapshots, Subvolumes oder die Dateisystemprüfung im laufendem Betrieb usw.

Linux | OSBN

Btrfs - no risk no fun

Ich verfolge die Entwicklung von Btrfs, dem zukünftigen Linux-Filesystem der Marke eierlegender Wollmilchsau, nun schon seit geraumer Zeit.

Gestern hat mich mal wieder der Teufel geritten und ich habe meine Rootpartition von Arch kurzerhand von ext4 auf btrfs umstellt.

Als erstes habe ich sichergestellt, dass das Paket btrfs-progs installiert ist.

Danach habe ich den Rechner mit dem Installationsmedium von Arch gebootet.

Mittels “fsck.ext4 -f /dev/sda3” habe ich vorsichtshalber erst mal das vorhandene Dateisystem auf Fehler getestet. Als das keine Probleme ausgespuckt hat, habe ich kurzerhand mittels “btrfs-convert /dev/sda3” meine Rootpartition von ext4 auf btrfs konvertiert. Hier muss man durchaus einige Zeit warten. Nach dem Konvertieren habe ich dann die “neue” Rootpartition gemountet und die /etc/fstab angepasst indem ich beim Eintrag für die betreffende Partition ext4 gegen btrfs und fs_passno von 1 gegen 0 ausgetauscht habe.

Mutig (oder dumm) wie ich bin, habe ich dann gleich einmal einen Neustart hingelegt. Und schwups hat es eine Fehlermeldung gehagelt. Und zwar dass das Filesystem btrfs nicht bekannt sei. Nach einigen ratlosen Minuten habe ich dann wieder das Installationsmedium gebootet, die Partition gemountet und mir die Datei /etc/mkinitcpio.conf angesehen. Hier hatte ich zwar als Hook filesystems eingetragen, aber scheinbar mag das btrfs nicht. Da meines Wissens ein btrfs-Hook existiert habe ich diesen mal schnell hinzugefügt. Damit das ganze dann auch funktioniert, wollte ich dann noch “mkinitcpio -p linux” ausführen. Und wieder hat es peng gemacht. Ohne chroot funktioniert das ja nicht. Also noch schnell die Boot-Partition gemountet und mittels “chroot /mnt/arch” das ganze gechrootet. Nun hat auch “mkinitcpio -p linux” funktioniert. Also Neustart. Und wieder peng. Langsam genervt, habe ich erneut vom Installationsmedium gebootet. Mittels “blkid” habe ich dann mir mal alle Partitionen zu Gemüte geführt und diese mit den Einträgen in der /etc/fstab abgeglichen. Bingo, die UUID hat sich geändert. Also schnell noch diese in der /etc/fstab anpassen. Neustart. Kein Peng, sondern der gewohnte Bootvorgang.

System läuft, Daten sind noch da. Also noch einen Schritt weiter. Erneut habe ich die Datei /etc/fstab editiert und in die betreffende Zeile noch ein compress=lzo hinzugefügt, damit die Dateien, welche geändert werden bzw. neu hinzukommen, auch komprimiert werden. Was aber mit den bereits vorhandenen, die sich nicht ändern? Naja erst mal testen und deshalb… Neustart. Funktioniert. Also was nun mit den bereits vorhandenen Daten? Nach der einen oder anderen Suchabfrage bei Google hatte ich die Lösung. Mit dem Befehl “find -xdev -type f -exec btrfs fi defrag ‘{}’ ;” werden vorhandene btrfs-Filesystem defragmentiert und dabei auch noch komprimiert, sofern der Eintrag in der /etc/fstab vorhanden ist.

Mal sehen, wie sich btrfs nun schlägt. Bisher habe ich noch keine negativen Effekte erlebt. Gut, nach nicht mal 24 Stunden ist das auch kein Wunder. Sollte es wirklich richtig Peng machen, werde ich einfach die ext4-Sicherung einspielen und hier noch einen Artikel schreiben. Alles in allem ist das aber alles kein Hexenwerk. Sofern man die Dinge berücksichtigt, die ich nicht berücksichtigt habe. ;-) Trotzdem will ich noch einmal ganz deutlich sagen, dass btrfs noch nicht als stabil gekennzeichnet ist. Deswegen Benutzung auf eigene Gefahr. Genau deswegen bleibt /home bei mir auch erst einmal ext4, da hier wesentlich mehr Daten lagern und eine Datensicherung nicht mal eben eingespielt ist.

Linux | OSBN