Ja, ja, ist gut, #bcachefs bekomme ist ebensogut wie #btrfs kaputt -.-
Schlagwort-Archive: BTRFS
adlerweb // BitBastelei 2023-11-07 22:24:59
Tage seit #btrfs ein System zerstört hat: 0.
adlerweb // BitBastelei 2023-07-31 20:11:05
Heute morgen verabschiedete sich eines meiner System. Ursache war – yet again – #btrfs. Obwohl noch mehr als 50GB Platz war, verweigerte das system beharrlich jeden Schreibversuch: No space left on device. Ursache ist ein good old Fragmentierung. Ja, es ist 2023 und sowas ist offenbar noch immer nicht gelöst. Leider ist es auch etwas schwerer als einfach nur "defrag" zu starten. Das heißt bei BTRFS "balance" und benötigt dummerweise freien Platz. Man muss also USB (oder yolo-tmpfs) anhängen.
BTRFS: Dateisystem mit mehreren Festplatten vergrößern
Das ist jetzt doof – Platte voll. Und das auf einem Multi-Device/RAID BTRFS-System. Die unterliegenden LUNs zu vergrößern ist kein wirkliches Problem, aber btrfs zeigte sich etwas widerspenstig: Die meisten Anleitungen empfehlen folgendes:
btrfs filesystem resize max /mnt/data
Leider scheint es bei multi-device keine reaktion zu geben. Der Trick: Dieser Befehl lässt nur die erste Festplatte wachsen. Hat man mehrere muss man den Befehl für jede LUN separat ausführen, die Plattennummer wird dabei als ID mitgegeben:
btrfs filesystem resize 2:max /mnt/data
Die IDs aller beteiligten Platten kann man mit
btrfs filesystem show /mnt/data
anzeigen. Wurden alle Platten vergrößert kann man natürlich auch eine bash-Schleife bemühen um den Befehl für alle abzusetzen.
for i in {1..8} ;do btrfs filesystem resize $i:max /mnt/data/ ;done
BTRFS-Recovery
Narf… Das war zu viel. Durch einen Umbau hatte sich offenbar ein Kabel im Lüfter meines Chipsatzes verheddert – keine gute Voraussetzung, wenn man mal eben Wine neu kompiliert. Es kommt, was kommen musste: Kernel panic.
Nunja, Fehler gefunden, weiter gehts. Nicht. Zwar startete das System, meine Home-Partition blieb aber verschwunden. Kurzer Blick auf den Aufbau: Mein Home liegt auf einer separaten Partition, ist mit LUKS verschlüsselt und nutzt – da ich die gigabyteweise IRC-Logs vorratsdatenspeichere und transparente Komprimierung wollte – BTRFS. Das Log verrät: LUKS selbst läuft, mount hingegen scheint sich aufzuhängen. In dmesg sieht alles OK aus, nur die normalen BTRFS-Meldungen, keine Fehler.
Strange, aber Reboot fixed ja fast alles, also schnell die magischen Zeichen eingetippt und zur Sicherheit im Rescue-Mode gestartet. Dort per Hand cryptsetup aufgerufen und erst mal btrfsck losgelassen. Kein Fehler. Mount? Nope.
OK, nun bin ich genervt, vor allem da die Kiste nicht unbedingt schnell bootet. Qemu to the rescue, also schnell ein Debian geklont und die Partition vorgesetzt. Schlechte Idee. Die bei Debian genutzten BTRFS-Libs/Module sind eine Nummer zu alt und können mit der Partition gar nichts anfangen. Ein Arch-Download später kann es weiter gehen.
Erst einmal ein normaler mount in der VM – vielleicht ist ja nur der Host kaputt, außerdem ist auf der CD ein älterer Kernel. Leider ohne erfolg, also VM-Reboot und den Hammer ausgepackt. Mit „mount -o recovery,nospace_cache“ lassen sich viele Fehler schon beheben, aber auch hier scheint der mount nichts zu vollziehen. Keine Reaktion, keine IO-Last, keine Fehlermeldung.
Die Lösung: btrfs_zero_log. Hiermit werden die offenen Transaktionen gelöscht. Die kann zwar zu Datenverlust von Änderungen, die kurz vor Absturz geschrieben wurden, führen, aber besser als gar keine Partition. Der mount in der VM war schlussendlich erfolgreich und auch der Host verfügte kurze Zeit später wieder über alle Dateien. Warum btrfsck das offenbar defekte Log nicht ankreidete ist mir allerdings ein Rätsel – sollte das nicht die Aufgabe des Tools sein?
btrfs und die delayed allocations (btrfs-delalloc)
Vor etwa einem Jahr hatte btrfs bei mir den Status „beste wo (derzeit für mich) gibt“ erhalten. RAID-Funktionen sind mir zwar im erprobten MD-Code lieber, aber endlich ein Dateisystem mit Kompression ohne Lizenzgewürge. Leider hält die Praxis der damaligen Erwartung – zumindest bei mir – nicht stand. Offenbar gibt es derzeit lediglich einen Thread namens „btrfs-delalloc-„, welcher sich um das Schreiben der Daten kümmert – und das nicht sonderlich schnell. Vor allem bei größeren Datenmengen macht sich dieses Konzept negativ bemerkbar: Vor etwa 15 Minuten beispielsweise wanderten 15GB eines Videoprojektes per NFS auf meienen Server. Der Vorgang lief schön flott, aber kurz drauf war Schluss. Keine HTTP-Antworten, keine neuen SSH-Verbindungen. Auf einer bereits offenen Konsole zeigt sich das gewohnte Bild: Ein Prozess namens „btrfs-delalloc-“ hängt auf 100% CPU, IO-Wait an der Decke und nichts reagiert mehr. (Anm: WWW und System liegen auf einem physikalisch separaten Speicher, da hängts sicher nicht…). Mir erscheint es so, als ob dieser Prozess sich um alle btrfs-Mounts kümmert – ist einer ausgelastet ist auch für alle anderen Sendepause. Sehr unschön.
Bis jetzt habe ich noch nicht so ganz raus, was es mit dem Prozess auf sich hat, aber wenn sich da keine Abhilfe findet muss auf dauer wohl doch wieder fusecompress mit einem reiferen Dateisystem aushelfen :/.
BitBastelei #76 (Part 2/2) Installation von Arch Linux
BitBastelei #76 (Part 2/2) Installation von Arch Linux
(85 MB) 00:49:04
2013-12-29 11:00 🛈Die grundlegenden Schritte lassen sich auf https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation finden.
Die Hintergründe warum ich installiere und was meine Ziele sind finden sich in Part 1.
Inhalt
======
00:13 Download
01:05 USB-Stick zur Installation vorbereiten
02:49 Dateiintegrität per md5sum prüfen
03:30 Boot von USB-Stick
05:20 Wenns nicht bootet: acpi=off
07:00 Internetzugang konfigurieren
08:37 Tastatur auf Deutsch umschalten
08:47 Partitionieren der Festplatte
12:21 Formatieren der Partitionen (1 swap/ext2)
13:14 Verschlüsseln einer Partition mit cryptsetup
16:28 Formatieren der Partitionen (2 btrfs)
17:30 Mounten der Partitionen
18:44 Mirrorliste
19:49 Installation des Grundsystems
21:18 Erstellen einer fstab
21:47 Wechsel ins neue System
22:07 Konfiguration: locale-gen, Sprache, Keymap, Zeitzone, Hostname
24:40 initrd für Verschlüsselung anpassen
26:04 Bootloader installieren & konfigurieren
28:20 Passwort setzen
28:44 Erster Start ins neue System
29:50 Netzwerk & Installation von SSH
30:29 Dienste per Systemd
31:18 Desktop Environments: KDE/GNOME/XFCE/LXDE
33:15 Softwareinstallation: Gruppen, Provider, Optionale Abhängigkeiten, Suche
36:06 AUR: Übersicht
37:37 AUR: Installation per Hand
40:45 AUR: Installation per yaourt
43:38 fstab: Kompression für btrfs
45:16 Anlegen eines Users
45:34 Installation eines Grafikservers
46:10 Start des LXDM
46:37 Netzwerkkonfiguration per NetworkManager
47:25 Deutsche Tastatur in der grafischen Oberfläche
47:53 Anpassen des Panels: Akkumonitor
48:20 Fazit
Ergänzungen:
============
02:19 – Korrektur: bs=4M – dd if=archlinux….iso of=/dev/sdx bs=4M
07:53 – Wenn bereits beim Booten ein Netzwerkkabel eingesteckt ist bezieht der Rechner bereits eine IP, dieser Schritt kann dann entfallen
08:29 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Wireless
10:03 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Using_cgdisk_to_create_GPT_partitions
11:40 – SWAP = Auslagerungsspeicher, Erweiterung des RAMs auf der Festplatte. Hiermit kann das System selten genutzte Daten des Arbeitsspeichers auf die Festplatte verschieben und so den schnelleren RAM zur Verfügung halten.
20:26 – https://wiki.archlinux.org/index.php/Grub#UEFI_systems_2
42:53 – …und ein RM, welches jedoch auch OK aussieht…
46:49 – Wenn man immer Netzwerk möchte sollte man den Dienst automatisch starten: „systemctl enable NetworkManager“
Hinweise:
=========
Nicht vergessen: Es gibt keine 100%ige Sicherheit. Da die Bootdateien hier zum Beispiel nicht verschlüsselt sind könnte ein Angreifer an dieser Stelle ansetzen und den Kernel infizieren. Erschweren kann man dieses vorgehen z.B. durch ein Bootloader-Passwort, einen modifizierten Bootloader für verschlüsselte Partitionen oder durch dsa Auslagern der Boot-Dateien auf einen USB-Stick. Auch kann man z.T. mit Kältespray und entsprechender Hardware das RAM auslesen und so den Verschlüsselungskey zusammensetzen. Ebenfalls bringt die Verschlüsselung nichts, wenn eine Applikationslücke genutzt wird.
ext4 vs. BTRFS – mal wieder
OK, ok, zugegeben, das Thema gibt’s zu Hauf im Netz, aber ich vertraue lieber eigenen Zahlen: Was ist schneller: ext4 oder btrfs? Hintergrund ist ein Backupzwischensystem, welches große Datenmengen schnell verarbeiten muss. Die Kompression von BTRFS wäre angesichts der Kosteneinsparung durch weniger Plattenverbrauch ein schöner Bonus, aber darf nicht auf Kosten der Geschwindigkeit gehen.
Das System ist ein „Low-End“ Dualcore (Intel(R) Pentium(R) CPU G645 @ 2.90GHz) mit 16GB RAM und 4 Hitachi Deskstar 5K3000 á 2TB. Die Platten mit 5300rpm sehen zwar auf den ersten Blick etwas schwachbrüstig aus, da die Daten aber vermutlich sehr groß und entsprechend hoffentlich am Stück geschrieben werden sollte die geringe Drehzahl hoffentlich nicht wirklich ins Gewicht fallen. Das Mainboard (ASRock H77 Pro4/MVP) verfügt über zwei SATA-Controller – der Intel® H77 steuert neben 4 SATA2-Ports zusätzlich 2 Ports mit SATA3 bei, ein ASMedia ASM1061 stellt 2 zusächliche SATA3-Ports bereit. Die Platten wurden über die SATA3-Ports an beide Controller verteilt.
Die Tests liefen auf einem Arch Linux x86_64-System mit Kernel 3.11.2, als RAID kam das im Kernel enthaltene md-Framework zum Einsatz, auf die bei BTRFS integrierte RAID-Funktion verzichte ich, da ich separate Schichten für besser wartbar halte.
Erst einmal die rohen Werte der Platte: Diese lieferten im Test jeweils etwa 140MB/s sequential Read.
Erster Versuch: 1GB sequential Write, die Platten werden dabei erst mal als RAID5 genutzt, in der Hoffnung, dass die Geschwindigkeit noch ausreichend ist. Das Ergebnis ist etwas ernüchternd:
1GB Sequencial File Write
RAID5, EXT4 99MB/s
RAID5, BTRFS 134MB/s
RAID5, BTRFS (LZO) 144MB/s
BTRFS liegt zwar klar vor ext4 und auch die Kompression bringt auf Grund der gut komprimierbaren Quelle einen Geschwindigkeitsschub, insgesamt liegt die Leistung aber unter meinen Anforderungen – 144MB/s könnte die 2GBit/s Uplink grade so bewältigen, aber eigentlich hätte ich schon gerne noch etwas Reserve… Die Antwort dürfte klar sein: Da die Daten hier nur zwischengelagert werden bin ich auf das RAID5 nicht angewiesen, also RAID0 ftw – der erste Blick aufs rohe Device ist vielversprechend: 490MB/s sind ein guter Start – und was machen die Dateisysteme daraus?
RAID0, EXT4 349MB/s
RAID5, BTRFS 376MB/s
RAID5, BTRFS (LZO) 382MB/s
Viel ändert sich nicht – BTRFS mit Kompression erreicht gegenüber ext4 knapp 10% höhere Schreibraten. Die 380MB/s dürften erst bei etwa 4GBit/s uplink an ihre Grenzen stoßen – bis die fällig sind dürfte eher der Plattenplatz ausgehen. Sieger gefunden würde ich sagen: BTRFS schlägt ext4 sowohl bei Geschwindigkeit als auch beim Funktionsumfang – ob es auch die Stabilität der ext-Systeme nacheifern kann wird die Zeit zeigen.