Ntfs2btrfs-Technik zur In-Place-Konvertierung des NTFS-Dateisystems in das Open-Source-Dateisystem Btrfs

 (github.com/maharmstone)
1 Punkte von GN⁺ 2024-12-01 | 1 Kommentare | Auf WhatsApp teilen
  • Ntfs2btrfs ist ein Werkzeug zur In-Place-Konvertierung des Microsoft-NTFS-Dateisystems in das Open-Source-Dateisystem Btrfs und arbeitet ähnlich wie btrfs-convert für ext2
  • Vor der Konvertierung wird das Original-Image als Reflink-Kopie unter image/ntfs.img gespeichert; wenn das Konvertierungsergebnis beibehalten werden soll, kann dieses Image gelöscht werden, um Speicherplatz freizugeben
  • Unter Windows wird es in einer Administrator-Eingabeaufforderung mit ntfs2btrfs.exe D:\ ausgeführt, unter Linux mit Root-Rechten per ntfs2btrfs /dev/sda1
  • Es funktioniert nicht auf dem Boot-Laufwerk oder auf Laufwerken mit einer aktuell verwendeten pagefile; bei Nutzung von WinBtrfs muss zum Löschen des image-Subvolumes zuerst das Read-only-Flag entfernt werden
  • Zum unterstützten Umfang gehören Dateien, Verzeichnisse, symbolische Links, Sicherheitsdeskriptoren, alternative Datenströme, NTFS-Rollback und die Erhaltung von LXSS-Metadaten, verschlüsselte Dateien und ungewöhnliche Clustergrößen werden jedoch nicht unterstützt

Was Ntfs2btrfs macht

  • Ntfs2btrfs ist ein Werkzeug zur In-Place-Konvertierung eines NTFS-Dateisystems in Btrfs
  • Das Original-Image wird als Reflink-Kopie unter image/ntfs.img gespeichert
    • Wenn das Konvertierungsergebnis beibehalten werden soll, kann diese Datei gelöscht werden, um Speicherplatz freizugeben
  • Das Werkzeug wird als stabil bezeichnet, enthält aber den Hinweis, dass der Autor bei Problemen keine Verantwortung übernimmt
  • Als weiteres sehenswertes Projekt wird der Windows-Btrfs-Dateisystemtreiber WinBtrfs verlinkt
  • Verwendet wird Code aus ntfs-3g-system-compression von Eric Biggers, der die „WOF compressed data“ von Windows 10 per Reverse Engineering analysiert hat

Verwendung und Einschränkungen

  • Unter Windows wird es in einer Administrator-Eingabeaufforderung ausgeführt
    • ntfs2btrfs.exe D:\
  • Unter Linux wird das Block-Device mit Root-Rechten angegeben
    • ntfs2btrfs /dev/sda1
  • Unter Windows können die folgenden Ziele nicht konvertiert werden

    • Boot-Laufwerk

      • Laufwerke mit einer aktuell verwendeten pagefile
      • Bei Verwendung von WinBtrfs muss zum Löschen des image-Subvolumes zuerst das Read-only-Flag entfernt werden

Installationspfade

  • Unter Windows kann die neueste ZIP-Datei von der Releases-Seite heruntergeladen oder Scoop verwendet werden
  • Für Linux-Distributionen werden Pakete bereitgestellt
  • Auf anderen Distributionen oder Betriebssystemen muss direkt kompiliert werden

Kompilierung und Abhängigkeiten

  • Unter Windows wird das Quellverzeichnis mit einer aktuellen Version von MSVC geöffnet und in CMakeLists.txt Compile ausgeführt
  • Unter Linux erfolgt der Build mit cmake und make
    • mkdir build
    • cd build
    • cmake ..
    • make
  • Für den Build wird libfmt benötigt; die Bibliothek kann über den Paketmanager installiert werden
  • Für die Komprimierungsunterstützung werden zlib, lzo, zstd benötigt
    • Mit den CMake-Optionen WITH_ZLIB, WITH_LZO, WITH_ZSTD kann die jeweilige Unterstützung deaktiviert werden

Unterstützte Funktionen

  • Die folgenden Elemente können konvertiert oder erhalten werden

    • Dateien

    • Verzeichnisse

      • symbolische Links
      • weitere Reparse Points
      • Sicherheitsdeskriptoren
      • alternative Datenströme
      • DOS-Attribute
      • hidden, system usw.
      • Rollback zum ursprünglichen NTFS-Image
      • Erhaltung von LXSS-Metadaten

Nicht unterstützte Elemente

  • Alte erweiterte Attribute von Windows werden nicht unterstützt
  • Große alternative Datenströme über 16 KB werden nicht unterstützt
  • Die Erhaltung des Case-Sensitivity-Flags wird nicht unterstützt
  • Ungewöhnliche Clustergrößen, die nicht 4 KB entsprechen, werden nicht unterstützt
  • Verschlüsselte Dateien werden nicht unterstützt

Wichtige Änderungen aus dem Changelog

  • Das Release vom 2025-06-16 behebt Kompilierungsprobleme mit GCC 15
  • Das Release vom 2024-01-15 behebt ein Kompilierungsproblem unter GCC 14, das durch die standardmäßige Aktivierung von -Werror=incompatible-pointer-types entstanden ist
  • Das Release vom 2023-05-01 behebt Probleme mit der Reihenfolge von Inline-Extent-Items und dem Level-Wert von Metadata-Items
    • Beide Probleme sollen laut Angabe nicht durch btrfs check diagnostiziert werden
    • ADS mit übermäßig langen Namen werden nun übersprungen
  • Das Release vom 2022-08-12 enthält die Option --no-datasum, die Erhaltung von LXSS/WSL-Metadaten, eine Korrektur für die Erkennung von Laufwerksbuchstaben in Kleinbuchstaben sowie einen Fix für Beschädigungen bei der Platzierung von Dateien im letzten 1-MB-Bereich
  • Das Release vom 2021-09-23 fügt Btrfs-Komprimierungsunterstützung und Rollback-Unterstützung hinzu
    • Die Komprimierung unterstützt zlib, lzo, zstd
    • Die Hash-Algorithmen xxhash, sha256, blake2 werden zusätzlich unterstützt
    • Sicherheitsdeskriptoren im NT4-Stil werden ebenfalls unterstützt
    • Die Konvertierungsgeschwindigkeit bei Volumes mit vielen Inodes wurde verbessert
    • Außerdem wurde ein Bug behoben, der Dateisystembeschädigungen verursachte, die btrfs check nicht erkennen konnte
  • Das Release vom 2021-01-05 enthält Fehlerbehebungen zu NTFS-Komprimierung, „WOF compressed data“ und Problemen rund um Sparse Files

Wenn Windows von Btrfs gebootet wird

  • Laut Angabe ist es unter passenden Bedingungen möglich, Windows von einem mit diesem Werkzeug konvertierten Btrfs zu booten
  • Als zugehöriges Projekt wird Quibble verlinkt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-12-01
Meinungen auf Hacker News

  • Der Link zu Quibble war deutlich interessanter: ein offen und erweiterbar reverse-engineerter Windows-Kernel-Bootloader: https://github.com/maharmstone/quibble

  • Wenn man das bei ZFS machen würde, würde ich wohl eine Schicht hinzufügen, die andere Dateisystemformate liest und ZFS-Blockpointer synthetisiert.
    Dann könnte ZFS andere Dateisysteme lesen und beim Schreiben nach und nach alles neu schreiben. Wenn ZFS eine Funktion zum Umschreiben von Blockpointern hätte, könnte man es alles neu schreiben lassen und die Konvertierung abschließen. Aber ich habe schon früher erklärt, dass ZFS kein richtiges Content-Addressed-Storage(CAS)-Dateisystem ist, weshalb es so eine Funktion nicht hat und auch nicht haben kann.

  • Kann jemand, der hier BTRFS nutzt, sagen, wie es heutzutage um die Stabilität steht? Früher habe ich viele gruselige Geschichten gesehen.

    • Es ist der Standard bei openSUSE, deshalb nutze ich es seit Jahren auf meinem Haupt-PC und Laptop, und dabei habe ich gemerkt, dass Snapshots genau die Funktion sind, von der ich nicht wusste, dass ich sie wollte.
      Probleme hatte ich nie, aber es ist lästig, dass der freie Speicher, den BTRFS sieht, und der freie Speicher, den der Rest des Betriebssystems sieht, nicht immer übereinstimmen. In der Praxis wurde das aber nur selten zu einem echten Problem.
    • Ich nutze seit über 10 Jahren auf meinem privaten Laptop, auf Servern und Embedded-Geräten ausschließlich BTRFS und hatte kein einziges Problem.
      Abgesehen von Datenbank-Workloads halte ich es für das führende Dateisystem unter Linux; ich verstehe kaum, warum man ein anderes Dateisystem verwenden sollte.
    • Ich nutze es seit Jahren auf privaten Geräten und für btrbk-Backups, ohne Probleme.
    • Nach weniger als einem Jahr ist es mir unter Tumbleweed um die Ohren geflogen, als die Platte vollgelaufen ist.
      Ich habe versucht, in einer parallelen Installation auf die kaputte Partition zuzugreifen und sie zu reparieren, aber ohne Erfolg.
    • Btrfs frisst meine Daten langsam auf. Kleine Dateien oder einzelne Sektoren großer Dateien werden zufällig komplett zu Nullwerten.

  • Das hätte ich vor 2 Monaten gebraucht. Ich musste eine Festplatte mit über 10 TB Daten von NTFS weg formatieren.
    Tolles Projekt.

  • Ich wäre ziemlich überrascht, wenn sogar Dateien mit LZX-Kompression unterstützt würden.
    Das ist etwas anderes als die Dateikompression aus Zeiten von Windows 2000 und muss mit compact.exe /C /EXE:LZX (filename) aktiviert werden.

  • Ich habe es früher einmal ausprobiert, und das Ergebnis war eine schreibgeschützte Festplatte. Ich hoffe, es ist seitdem besser geworden.

  • Das hier sichtbare Ausmaß an Tollkühnheit sprengt jede Skala.

    • So gefährlich ist es nicht, wie man vielleicht denkt.
      Der Standardansatz besteht darin, im alten Dateisystem eine große Datei für die Metadaten des neuen Dateisystems zu reservieren und dann alle Dateien des alten Dateisystems zu durchlaufen, wobei man mit fiemap() neue Extents erzeugt, die auf die vorhandenen Daten zeigen. Geschrieben wird nur in den zuvor reservierten Bereich.
      Der Superblock wird erst ganz am Ende überschrieben, und vorher kann man prüfen, ob die Inhalte des alten und des neuen Dateisystems identisch sind.
    • Vor ein paar Jahren war es eher so, als würde man mit Kettensägen jonglieren: https://github.com/maharmstone/ntfs2btrfs/issues/9
      Damals habe ich beim Herumprobieren ein paar ziemlich fiese Bugs aufgespürt, und ich hoffe, dass es jetzt stabiler ist.
    • Apple hat mit der Migration von HFS+ zu APFS in Milliarden realer OS-X-/iOS-Installationen etwas Ähnliches geschafft.
      Wie andere schon sagen: Man kann das in großem Maßstab systematisch machen, aber natürlich ist Vorsicht geboten.
    • Das ist nicht btrfs unter Linux.
      „WinBtrfs ist ein Windows-Treiber für Btrfs, das Linux-Dateisystem der nächsten Generation. Er wurde von Grund auf neu implementiert, enthält keinen Linux-Kernel-Code und sollte auf jeder Windows-Version ab Windows XP funktionieren. Außerdem ist er Teil des freien Betriebssystems ReactOS.“
      Das stammt von der Seite des ntfs2btrfs-Maintainers.
      https://github.com/maharmstone/btrfs
    • Nachdem ich gesehen habe, wie Windows bei In-Place-Upgrades zweimal kaputtging, würde ich einfach eine neue Festplatte oder einen neuen Computer kaufen und neu anfangen.
      Ich weiß, dass das hier ein anderer Fall ist, aber die Zeit, die in diesen Daten steckt, ist deutlich mehr wert als eine neue Festplatte. Für mich persönlich wäre es das Risiko nicht wert. Wenn die Daten nicht wichtig sind oder gut gesichert wurden und man beim Finden von Bugs helfen will, kann man es natürlich ausprobieren.

  • Wirklich cool, aber die meisten werden davon wahrscheinlich erst mindestens eine Woche nachdem sie die seit 2 Jahren aufgeschobene Formatierung ihres NTFS-Laufwerks endlich erledigt haben erfahren.