Open-Source-btrfs-Treiber für Windows: WinBtrfs

 (github.com/maharmstone)
1 Punkte von GN⁺ 2024-04-08 | 1 Kommentare | Auf WhatsApp teilen
  • WinBtrfs v1.9 ist ein Treiber, der das Linux-Dateisystem Btrfs unter Windows les- und schreibbar macht; er wurde von Grund auf neu implementiert, ohne Linux-Kernel-Code zu verwenden
  • Er sollte ab Windows XP funktionieren, ist auch im freien Betriebssystem ReactOS enthalten, und Btrfs auf einem unter Linux erstellten MD-Software-RAID benötigt zusätzlich WinMD
  • Der Funktionsumfang umfasst Lesen/Schreiben, RAID0/1/10/5/6, Subvolumes und Snapshots, reflink copy, send/receive, zlib/LZO/Zstd-Kompression, LXSS-Unterstützung sowie Mapping von ACLs, ADS und Berechtigungen
  • Zur Installation lädt man das neueste Release herunter und installiert btrfs.inf oder nutzt Chocolatey bzw. Scoop; in Secure-Boot-Umgebungen von Windows 10/11 kann eine Registry-Änderung oder das Deaktivieren von Secure Boot nötig sein
  • Das Projekt wird unter LGPL veröffentlicht, übernimmt aber keine Verantwortung für Schäden am Dateisystem; es soll zwar für den Alltagsgebrauch geeignet sein, empfiehlt aber Backups

Was WinBtrfs macht

  • WinBtrfs ist ein Windows-Treiber für Btrfs, das Next-Generation-Dateisystem von Linux
  • Er wurde ohne Linux-Kernel-Code von Grund auf neu implementiert und sollte ab Windows XP funktionieren
  • Er ist auch im freien Betriebssystem ReactOS enthalten
  • Wenn sich das Btrfs-Dateisystem auf einem unter Linux erstellten MD-Software-RAID-Gerät befindet, wird WinMD benötigt, damit es unter Windows sichtbar wird
  • Verwandte Projekte sind der experimentelle Bootloader Quibble, der Windows von Btrfs booten kann, sowie Ntfs2btrfs, das NTFS-Dateisysteme inplace konvertiert

Unterstützte Funktionen

  • Grundfunktionen
    • Lesen und Schreiben von Btrfs-Dateisystemen
    • Erkennen von Btrfs-Partitionen, die Windows normalerweise ignorieren würde
    • Btrfs-Volumes ohne Partition
    • Asynchrones Lesen und Schreiben
    • Caching, free-space cache, free space tree
  • RAID und Volume-Verwaltung
    • RAID0, RAID1, RAID10
    • RAID5, RAID6
    • Balancing, einschließlich Fortsetzen eines unter Linux gestarteten balance
    • Hinzufügen und Entfernen von Geräten
    • degraded mount
    • Verkleinern und Erweitern von Volumes
  • Dateisystemfunktionen
    • Shell-Erweiterung zum Erstellen und Identifizieren von Subvolumes und Snapshots
    • Hardlinks, symbolische Links, reparse point
    • sparse file, preallocation
    • reflink copy
    • subvolume send und receive
    • scrubbing, TRIM/DISCARD
  • Windows-Linux-Interoperabilität
    • ACLs als xattr security.NTACL importieren und setzen
    • Alternate Data Streams als xattr speichern; zum Beispiel wird :Zone.Identifier als user.Zone.Identifier gespeichert
    • Mapping von Linux-Benutzern und Windows-Benutzern
    • Unterstützung für LXSS, also „Ubuntu on Windows“
    • Metadata-passthrough für Berechtigungen und Ähnliches für LXSS
    • Unterstützung des Verzeichnis-Flags für Groß-/Kleinschreibung in Windows 10
  • Kompression und Kompatibilitätsfunktionen
    • zlib-, LZO- und Zstd-Kompression
    • Das Metadata UUID incompat flag wird gemäß Linux 5.0 unterstützt
    • 3- und 4-Disk-RAID1 sowie xxhash-, sha256- und blake2-Checksummen werden gemäß Linux 5.5 unterstützt
    • block group tree wird gemäß Linux 6.1 unterstützt

Noch ausstehende Arbeiten

  • Vollständige Unterstützung für fs-verity bleibt als Punkt für Linux 5.15 offen
  • Zoned-Unterstützung bleibt als Punkt für Linux 5.11 offen, mit dem Hinweis, dass HM-SMR unter Windows möglicherweise nicht unterstützt wird
  • Defragmentierung, Btrfs quota, vollständige Unterstützung für transaction log sowie Unterstützung für Windows transactions, also TxF, stehen auf der To-do-Liste

Installation und Entfernung

  • Zur Installation lädt man das neueste Release herunter, entpackt es und wählt per Rechtsklick auf btrfs.inf die Option Install
  • Der Treiber ist signiert und sollte auf aktuellen Windows-Versionen direkt funktionieren
  • Wenn Secure Boot unter Windows 10 oder 11 aktiviert ist, kann eine Registry-Änderung nötig sein, damit der Treiber geladen wird
    • Als einfachere Methode wird auch vorgeschlagen, Secure Boot im BIOS zu deaktivieren
    • Windows 11 verlangt Secure Boot bei der Installation nur schwach; nach der Installation soll es auch deaktiviert funktionieren
  • Installation über Paketmanager ist ebenfalls möglich
    • Chocolatey: choco install winbtrfs
    • Scoop: scoop bucket add nonportable, scoop install winbtrfs-np -g
  • Die Entfernung ist über den Befehl RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultUninstall 132 btrfs.inf oder durch Entfernen des „Btrfs controller“ im Device Manager möglich
  • Wenn die Entfernung per Registry erfolgen muss, setzt man den Wert HKLM\SYSTEM\CurrentControlSet\services\btrfs\Start auf 4, deaktiviert damit den Dienst, startet neu und löscht danach den Schlüssel sowie C:\Windows\System32\drivers\btrfs.sys

Build und Benutzer-Mapping

  • Für den Build mit Visual C++ 2019 genügt es, das Verzeichnis zu öffnen und CMake die Verarbeitung übernehmen zu lassen; wenn das Windows DDK korrekt installiert ist, sollte es funktionieren
  • Für den Build unter Linux mit GCC wird ein Cross-Compiler i686-w64-mingw32 oder x86_64-w64-mingw32 benötigt
  • Benutzer-Mappings werden im Registry-Schlüssel HKLM\SYSTEM\CurrentControlSet\services\btrfs\Mappings gespeichert
    • Man erstellt ein DWORD mit dem Namen der Windows-SID und trägt den Linux-uid-Wert ein
    • Die aktuelle SID kann mit wmic useraccount get name,sid geprüft werden
  • Gruppen-Mappings werden unter GroupMappings gespeichert
    • Der Standardeintrag mappt die Windows-Gruppe Users auf gid 100, unter Linux normalerweise users
    • Durch Angabe einer Benutzer-SID kann festgelegt werden, dass von einem bestimmten Benutzer erstellte Dateien zu einer bestimmten Gruppe gehören
  • Zu beachten ist, dass Prozesse, die mit einem User-Access-Control-Token laufen, Dateien nicht mit dem Benutzerkonto, sondern mit der SID BUILTIN\Administrators erstellen

WSL/LXSS-Unterstützung

  • Der Treiber kann Linux-Metadaten an aktuelle LXSS-Versionen durchreichen
  • Um dies zu verwenden, setzt man /etc/wsl.conf in der Bash-Eingabeaufforderung von Windows in folgender Form
    • [automount]
    • enabled = true
    • options = "metadata"
    • mountFsTab = false
  • Änderungen werden beim nächsten Neustart übernommen
  • Es soll möglich sein, per chroot in eine echte Linux-Installationsumgebung zu wechseln

Kommandozeilenoperationen

  • shellbtrfs.dll stellt eine GUI-Schnittstelle bereit, kann aber über rundll32.exe einige Aufgaben auf der Kommandozeile ausführen
  • rundll32 hat keine Möglichkeit, Fehlercodes zurückzugeben, daher können Befehle stillschweigend fehlschlagen
  • Allgemeine Befehle
    • CreateSubvol <path>
    • CreateSnapshot <source> <destination>
    • ReflinkCopy <source> <destination>; kann Wildcards und mehrere Quelldateien entgegennehmen
  • Befehle, die Administratorrechte benötigen
    • SendSubvol <source> [-p <parent>] [-c <clone subvol>] <stream file>
    • RecvSubvol <stream file> <destination>
    • StartScrub <drive>
    • StopScrub <drive>

Wichtige Einschränkungen bei der Fehlerbehebung

  • Es wird angenommen, dass alle Dateinamen in UTF-8 kodiert sind
  • Für spätere Versionen von Windows 10 mit aktiviertem Secure Boot heißt es, dass durch Microsofts Signaturanforderungen eine Bedingung entstanden sei, die für Open-Source-Treiber offenbar nicht nutzbar ist
    • Der Workaround besteht darin, unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy ein DWORD UpgradedSystem anzulegen, es auf 1 zu setzen und anschließend neu zu starten
    • Alternativ kann Secure Boot im BIOS deaktiviert werden
  • Dass das Laufwerks-Root in LXSS nicht zwischen Groß- und Kleinschreibung unterscheidet, ist ein von Microsoft hartcodiertes Verhalten
  • Dem Windows-eigenen Formatierungsdialog kann Btrfs nicht hinzugefügt werden, da die Liste der Dateisysteme hartcodiert ist
    • Für die Btrfs-Formatierung nutzt man das enthaltene mkbtrfs.exe
    • Wenn keine Btrfs-spezifischen Optionen benötigt werden, ist auch format /fs:btrfs möglich
  • Synology NAS scheint LVM auf Blockgeräten zu verwenden und kann ohne LVM-Treiber für Windows nicht gemountet werden
  • Thecus NAS verwendet Linux MD RAID, daher muss WinMD mitinstalliert werden
  • Die Berechtigungsmodelle von Windows und POSIX sind zu unterschiedlich, um ein praktikables Mapping zu haben; für Dateien, die unter Windows nicht bearbeitet werden sollen, können Windows-ACLs erstellt werden

Änderungen in v1.9

  • v1.9 wurde am 15. März 2024 veröffentlicht
  • Unterstützung für block group tree aus Linux 6.1 wurde hinzugefügt
  • Ein Problem wurde behoben, bei dem das System unter hoher Last hängen blieb
  • Optionen /blockgrouptree und /freespacetree wurden zu mkbtrfs hinzugefügt
  • Der Standardwert für /noholes in mkbtrfs wurde wie unter Linux auf aktiviert gesetzt
  • Unterstützung für CRC32C-Instruktionen auf aarch64 wurde hinzugefügt

Debug- und Mount-Optionen

  • WinBtrfs unterteilt Debug-Meldungen in drei Stufen: errors/FIXMEs, warnings und traces
  • Der Treiber in der Release-Version protokolliert nur errors und FIXMEs per DbgPrint; sie sind mit Microsoft DebugView sichtbar
  • Um bei Problemberichten das vollständige Debug-Log anzuhängen, verwendet man die Debug-Version des Treibers und Registry-Einstellungen
    • DebugLogLevel: 0 bedeutet keine Meldungen, 1 errors/FIXMEs, 2 inklusive warnings, 3 alles bis hin zu traces
    • LogDevice: optional, serielles Ausgabegerät
    • LogFile: optional, Ausgabedatei
  • Mount-Optionen werden unter HKLM\SYSTEM\CurrentControlSet\Services\btrfs in Unterschlüsseln der jeweiligen Dateisystem-UUID gespeichert
  • Wichtige Optionen
    • Ignore: lädt das betreffende Dateisystem nicht
    • Readonly: erlaubt wie das Linux-Flag ro keine Schreibzugriffe
    • Compress, CompressForce, CompressType: Standardkompression, erzwungene Kompression und bevorzugte Kompressionsmethode festlegen
    • FlushInterval: Intervall für Metadata flush; Standardwert sind wie unter Linux 30 Sekunden
    • SubvolId: ID des als Root zu mountenden Subvolumes
    • SkipBalance: überspringt das Fortsetzen eines beim letzten Herunterfahren laufenden balance
    • NoTrim: deaktiviert TRIM-Unterstützung
    • AllowDegraded: erlaubt das Mounten eines degraded Volume mit fehlendem Gerät
    • NoDataCOW: deaktiviert copy-on-write für neue Dateien und entspricht dem Linux-Flag nodatacow

Lizenz und Haftungsumfang

  • Das gesamte Projekt wird unter der GNU Lesser General Public Licence, also LGPL, veröffentlicht
  • Die Nutzung der Software erfolgt auf eigene Verantwortung; es wird ausdrücklich keine Haftung für mögliche Schäden am Dateisystem übernommen
  • Obwohl sie für den Alltagsgebrauch geeignet sein soll, werden Backups empfohlen
  • Für enthaltenen Drittanbieter-Code sind Urheberrechts- und Lizenzhinweise zu Zlib, LZO, Zstd, BLAKE2 und SHA256 enthalten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-04-08
Meinungen auf Hacker News

  • Ich wollte es eine Zeit lang ausprobieren, aber ein Blick durch die GitHub-Issues hat mich sofort davon abgebracht.
    Ich sah Probleme wie Bluescreens, Hänger, stark ansteigende Auslastung und Beschädigungen; für einen stabilen btrfs-/ZFS-Treiber würde ich gern bezahlen.
    Ich verstehe nicht so recht, warum solche Projekte nicht mehr Aufmerksamkeit bekommen.

    • Wenn du „gern bezahlen“ würdest: Es gibt einen Sponsoring-Link: https://github.com/maharmstone/btrfs?tab=readme-ov-file#dona...
    • Weil Microsoft es nicht unterstützt und Treiberentwickler den Windows-Kernel-Code nicht lesen können.
      Selbst wenn die genannten Probleme behoben werden, dürfte es deshalb weiterhin schwierig bleiben, Windows von btrfs zu booten.
      Andere Länder, andere Sitten: Vielleicht sollte man Windows einfach nur noch virtualisiert laufen lassen.

  • Wirklich beeindruckend, dass es ohne Linux-Code komplett neu implementiert wurde, und großartig, dass sogar XP/2k3 und ReactOS unterstützt werden.
    Das sollte ich auf einer meiner alten Maschinen einmal ausprobieren.

    • In der Rust-Welt gibt es einen interessanten Trend zu Bibliotheken ohne eigene Ein-/Ausgabe.
      Ich weiß nicht, worauf man dieses Phänomen am besten verlinkt, aber es gibt ein Issue zu einer I/O-losen QUIC-Bibliothek aus dem Jahr 2019: https://github.com/aiortc/aioquic/issues/4
      Es wäre wirklich schön, wenn auch Dateisysteme diesem Muster folgen würden.
      Wenn man Dateisystemlogik wiederverwenden und auf Windows, FUSE, Linux, lineare Adressspeicher in wasm usw. anwenden könnte, würden Portabilität, Wiederverwendung und Hackbarkeit enorm steigen.
    • ReactOS zielt auf API-Kompatibilität mit Windows ab, daher ist es nicht allzu überraschend, dass sowohl XP/2k3 als auch ReactOS unterstützt werden.

  • Verwandte Beiträge:
    WinBtrfs – A Windows driver for the next-generation Linux filesystem Btrfs - https://news.ycombinator.com/item?id=15177002 - September 2017, 100 Kommentare
    WinBtrfs v0.7 - https://news.ycombinator.com/item?id=12794214 - Oktober 2016, 1 Kommentar

  • Vor ein paar Wochen wollte ich es mit einer btrfs-Festplatte ausprobieren, habe es aber nicht richtig zum Laufen gebracht.
    Danach habe ich über WSL darauf zugegriffen; ein paar Mal funktionierte es, dann schlug es immer häufiger fehl, und später ließ es sich nicht einmal mehr mounten.
    Am Ende habe ich gemerkt, dass ich einfach von einer Linux-Live-ISO booten und Dateien zwischen dem Windows-Laufwerk und dem btrfs-Laufwerk kopieren/verschieben kann; inzwischen nutze ich die Fedora-Workstation-Live-ISO auf einem Ventoy-USB-Stick.

    • Klingt nach einer sehr authentischen Erfahrung.
      Jetzt kann man auch unter Windows Daten mit btrfs verlieren :-D

  • Ich nutze diesen Treiber seit einiger Zeit auf meinem Laptop.
    Das ist eine gemeinsame Umgebung: unter Linux für Arbeits-Coding, unter Windows für Spiele, Filme und Medien.
    Wenn man sich Sorgen um Datenbeschädigung auf btrfs-Partitionen und -Laufwerken macht, sollte man sich auf die Mount-Optionen im README konzentrieren.
    Für die Arch-Linux-Systempartition Ignore verwenden und für alles andere Readonly.
    Allerdings habe ich selbst bei einer vollständig gemounteten externen 20-TB-HDD mit btrfs-zstd:2-Kompression weder CPU-Spitzen noch Beschädigungen erlebt.

  • Ich empfehle, das README komplett zu lesen.
    Der Autor hat die Fragen beantwortet, die ich hatte, und noch einiges mehr.

  • Ich frage mich, wie hier behauptet werden kann, dass „einfaches und erweitertes“ RAID 5/6 unterstützt wird.
    btrfs selbst tut das nicht wirklich, und es ist auch unklar, was hier mit „einfach/erweitert“ gemeint ist: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...

    • Das ist nicht ganz richtig.
      Linux-btrfs unterstützt RAID5 grundsätzlich, aber es gibt bekannte Grenzfälle, die eine sichere Nutzung schwierig machen.
      Praktisch ist es eher „benutzbar, aber experimentell und nur für Entwickler“.
      WinBtrfs führt den RAID5-Modus lediglich als eines der Features auf, geht aber nicht wirklich darauf ein, wie gut er funktioniert.
      Auch Fragen in den entsprechenden Issues wurden ohne substanzielle Antworten geschlossen: https://github.com/maharmstone/btrfs/issues/293
      Bevor ich vom Entwickler keine klare Aussage zum Status und zu Tests bekomme, würde ich RAID 5/6 keine Daten anvertrauen.
    • Offenbar werden RAID0/1/10 als „einfaches“ RAID und RAID5/6 als „erweitertes“ RAID bezeichnet.
      Warum, weiß ich nicht; vielleicht weil Ersteres keine „fortgeschrittenen“ Paritätsberechnungen braucht.

  • Ich habe diesen Treiber und btrfs genutzt, um eine Bibliothek auf dem Steam Deck vorab zu befüllen.
    Über das Netzwerk hätte es zu lange gedauert, und mit meiner damaligen Internetverbindung wahrscheinlich noch 100-mal länger.
    Das könnte das erste Dateisystem seit FAT sein, das einfach so auf nix, Mac und Windows funktioniert.

    • Alle vergessen immer UDF

  • Hervorragend
    Falls jemand das langfristig oder in Produktion nutzt, würde mich interessieren, wie es in der Praxis war
    Ich habe gesehen, dass TRIM unterstützt wird, frage mich aber, ob auch RETRIM unterstützt wird
    Ich meine die Funktion, die benötigt wird, um bei der Laufwerksoptimierung Bereiche freizugeben, die anfangs nicht getrimmt werden konnten, weil die Command Queue voll war
    Mich interessiert auch, ob es für Leute, die ReFS nicht mögen, als NTFS-Alternative mit Datenparität taugt, und wie ausgereift es im Vergleich zu ZFS für Windows ist

    • Ich habe es einige Jahre lang eher leichtgewichtig auf meinem Hauptrechner genutzt
      Die Konfiguration bestand aus einer Windows-Partition, einer Linux-Partition (btrfs auf LUKS) und einer dritten btrfs-Partition zum Speichern von Dateien
      Ich nutze sie nicht oft, aber wenn, dann so unauffällig, dass ich ihre Existenz gar nicht bemerke
      Es fühlte sich an, als hätte Windows btrfs schon immer nativ lesen können, und bei meiner Nutzung, die nur aus einfachem Zugriff auf Dateien sowie Ändern und Löschen bestand, habe ich keine besonderen „fortgeschrittenen“ Funktionen verwendet
    • Einmal habe ich versehentlich einen Visual-Studio-Build aus einem git-Klon auf btrfs heraus gestartet, statt vom Hauptlaufwerk mit NTFS
      Als ich es bemerkte und den Build abbrach, waren zwei Ordner mit demselben Namen, aber unterschiedlichem Inhalt entstanden, und ich musste denselben Ordnernamen zweimal löschen
      Dieser Treiber scheint ein Nebenläufigkeitsproblem zu haben
    • Wenn man WinBTRFS und OpenZFS on Windows zusammen installiert, kann es zu Problemen kommen
      „Win OpenZFS driver and WinBtrfs driver dont play well with each other“
      https://github.com/openzfsonwindows/openzfs/issues/364
    • ReFS und Storage Spaces erfüllen diesen Zweck bereits, sind integriert und vollständig unterstützt
      Soweit ich gehört habe, hat BTRFS eine absurd lange Liste von Fehlern, bei denen es schon bei kleinsten Fehlgriffen hängen bleibt oder Daten beschädigt
      Etwas, dessen Zuverlässigkeit selbst auf dem nativen Betriebssystem fragwürdig ist, mit Gewalt in Windows hineinzuzwängen, grenzt an Wahnsinn
      Zum Herumspielen ist es okay, aber echte Daten würde ich dieser Kombination auf keinen Fall anvertrauen
      „Auf meinem 2-Disk-Mirror läuft es“ ist nur eine Anekdote, keine Daten

  • Ich frage mich, ob man damit Windows 10/11 von einem mit btrfs formatierten Windows-USB-Stick booten kann

    • Mit Rufus kann man 10/11 als „Windows To Go“ auf einem USB-SATA/NVMe-Laufwerksgehäuse installieren
      Ich habe Windows 10 eine Zeit lang täglich so genutzt; meiner Erfahrung nach funktionierte es ziemlich gut, aber es gibt ein paar Dinge zu beachten
      Man braucht eine stabile USB-Verbindung und ein USB-Laufwerksgehäuse mit einem zuverlässigen Controller-Chip, der nicht überhitzt
      Das Laufwerk sollte robust gegen Stromausfälle sein
      Leider kenne ich keine Quelle, die die Fähigkeit zum Umgang mit Stromausfällen bewertet
      Einige Laufwerke können bei einem plötzlichen Stromverlust erhebliche Probleme bekommen
      Gute Erfahrungen hatte ich mit einer Intel-Enterprise-SATA-SSD und mit einem NVMe-Laufwerk in einem Dockcase mit Kondensatoren
      Wenn das Laufwerk nicht mehr sichtbar ist, kann erneutes Einschalten helfen: https://dfarq.homeip.net/fix-dead-ssd/
      Außerdem sollte man automatische Backups einrichten
      Sehr nützlich ist das für Performance-Tests oder Firmware-Updates von Hardware, die nur unter Windows laufen
      Wenn man zwischen verschiedenen Computern wechselt, ist Windows nach dem Booten oft erst einmal verwirrt und man muss neu starten; danach funktioniert es
      Ich habe allerdings weder WinBTRFS noch ein separates Bootloader-Projekt ausprobiert, und dieser Bootloader scheint seit einigen Monaten derzeit kaputt zu sein
      Windows-VHD-Dateien mit Ventoy zu booten, könnte ebenfalls eine gute Option sein
    • Für sich allein reicht das nicht
      Man braucht zusätzlich einen separaten Bootloader
      Der Autor hat eine Implementierung namens Quibble erstellt, die ebenfalls btrfs unterstützt
      [0] https://github.com/maharmstone/quibble