1 ポイント 投稿者 GN⁺ 2024-12-01 | 1件のコメント | WhatsAppで共有
  • Ntfs2btrfsは、Microsoft NTFSファイルシステムをオープンソースのファイルシステム Btrfs へインプレース変換するツールで、ext2向けの btrfs-convert と似た方式で動作する
  • 変換前の元イメージは image/ntfs.imgreflinkコピーとして保存され、変換結果を維持する場合はこのイメージを削除して空き容量を確保できる
  • Windowsでは管理者コマンドプロンプトで ntfs2btrfs.exe D:\ を実行し、Linuxではroot権限で ntfs2btrfs /dev/sda1 を実行する
  • ブートドライブや、現在使用中の pagefile があるドライブでは動作せず、WinBtrfs使用時は image サブボリュームのreadonlyフラグを解除しないと削除できない
  • サポート範囲にはファイル、ディレクトリ、シンボリックリンク、セキュリティディスクリプタ、代替データストリーム、NTFSロールバック、LXSSメタデータ保存が含まれるが、暗号化ファイルと特殊なクラスタサイズはサポートしない

Ntfs2btrfsが行うこと

  • Ntfs2btrfs は、NTFSファイルシステムを Btrfs に インプレース変換するツール
  • 元イメージは image/ntfs.imgreflinkコピーとして保存される
    • 変換結果を維持する場合は、このファイルを削除して空き容量を確保できる
  • ツールは安定しているとされているが、問題が発生しても作者は責任を負わないという注意書きがある
  • Windows向けBtrfsファイルシステムドライバである WinBtrfs も、あわせて参照したいプロジェクトとして紹介されている
  • Windows 10の「WOF compressed data」をリバースエンジニアリングした Eric Biggersntfs-3g-system-compression のコードが使われている

使い方と制約

  • Windowsでは 管理者コマンドプロンプト で実行する
    • ntfs2btrfs.exe D:\
  • Linuxでは root権限 でブロックデバイスを指定する
    • ntfs2btrfs /dev/sda1
  • Windowsでは次の対象は変換できない
    • ブートドライブ

      • 現在使用中の pagefile があるドライブ
      • WinBtrfsを使う場合、image サブボリュームを削除するには先にreadonlyフラグを解除する必要がある

インストール方法

  • Windowsでは Releases page から最新のZipファイルを取得するか、Scoop を利用できる
  • Linuxディストリビューションごとのパッケージが提供されている
  • それ以外のディストリビューションやOSでは自分でコンパイルする必要がある

コンパイルと依存関係

  • Windowsでは最近の MSVC でソースディレクトリを開き、CMakeLists.txt からCompileを実行する
  • Linuxでは cmakemake でビルドする
    • mkdir build
    • cd build
    • cmake ..
    • make
  • ビルドには libfmt が必要で、パッケージマネージャからインストールできる
  • 圧縮サポートには zliblzozstd が必要
    • CMakeオプション WITH_ZLIBWITH_LZOWITH_ZSTD で各サポートを無効化できる

サポートされる機能

  • 次の項目を変換または保持できる
    • ファイル

    • ディレクトリ

      • シンボリックリンク
      • その他のreparse point
      • セキュリティディスクリプタ
      • 代替データストリーム
      • DOS属性
      • hidden、system など
      • 元のNTFSイメージへのロールバック
      • LXSSメタデータ保存

サポートされない項目

  • Windowsの古い 拡張属性 はサポートしない
  • 16KBを超える大きな 代替データストリーム はサポートしない
  • case-sensitivityフラグの保持はサポートしない
  • 4KB以外の特殊なクラスタサイズはサポートしない
  • 暗号化ファイル はサポートしない

変更履歴からわかる主な変化

  • 2025-06-16のリリースでは GCC 15 のコンパイル問題を修正
  • 2024-01-15のリリースでは、GCC 14-Werror=incompatible-pointer-types がデフォルトで有効になったことで発生したコンパイル問題を修正
  • 2023-05-01のリリースでは、inline extent itemの順序問題とmetadata item level値の問題を修正
    • これら2つの問題は btrfs check では診断されないとされている
    • 名前が長すぎるADSはスキップするよう変更された
  • 2022-08-12のリリースには、--no-datasum オプション、LXSS/WSLメタデータ保存、小文字ドライブレター認識の修正、最後の1MB領域へのファイル配置時の破損修正などが含まれる
  • 2021-09-23のリリースでは、Btrfs圧縮サポートとロールバックサポートを追加
    • 圧縮は zliblzozstd をサポート
    • ハッシュアルゴリズムは xxhashsha256blake2 を追加サポート
    • NT4スタイルのセキュリティディスクリプタもサポート
    • inodeが多いボリュームでの変換速度が改善
    • btrfs check で検出できないファイルシステム破損バグも修正
  • 2021-01-05のリリースには、NTFS圧縮、「WOF compressed data」、sparse file関連の問題修正が含まれる

WindowsをBtrfsから起動する場合

  • このツールで変換したBtrfsからWindowsを起動することは、条件が合えば可能とされている
  • 関連プロジェクトとして Quibble が紹介されている

1件のコメント

 
GN⁺ 2024-12-01
Hacker News の意見
  • Windows カーネルブートローダーを公開かつ拡張可能な形でリバースエンジニアリングした Quibble へのリンクのほうが、ずっと興味深かった: https://github.com/maharmstone/quibble

  • ZFS でこれをやるなら、別のファイルシステム形式を読み取って ZFS ブロックポインタを合成するレイヤーを追加することになりそう
    そうすれば ZFS が別のファイルシステムを読み取れるし、書き込みの過程で全体をゆっくり書き直せる。ZFS にブロックポインタの書き換え機能があれば、全体を書き直させて変換を終えられるだろうが、ZFS はちゃんとした**内容アドレスストレージ(CAS)**ファイルシステムではないので、そういう機能はなく、持つこともできないと以前説明したことがある

  • ここで BTRFS を使っている人がいたら、最近の安定性がどうなのか教えてもらえる? 昔は怖い事例をたくさん見た

    • openSUSE のデフォルトなので、数年にわたってメイン PC とノート PC で使っているが、スナップショットが自分が欲しかったとは知らなかった機能だと分かった
      問題は一度もなかったが、BTRFS が考える空き容量と OS の他の部分が考える空き容量が常に一致するわけではない点は厄介。それでも実際に問題になったことはまれ
    • 個人のノート PC、サーバー、組み込み機器で 10 年以上BTRFS だけを使ってきたが、一度も問題はなかった
      データベースのワークロードを除けば、なぜ他のファイルシステムを使うのか理解できないほど、Linux の代表的なファイルシステムだと思う
    • 個人の機器と btrbk バックアップで数年使っており、問題はなかった
    • 1 年も経たないうちに Tumbleweed でディスクが満杯になったら壊れた
      並列インストール環境から壊れたパーティションにアクセスして直そうとしたが、無駄だった
    • Btrfs が自分のデータをじわじわ食い潰している。小さなファイルや大きなファイルの一部セクタが、ランダムにすべてヌル値に変わる
  • 2 か月前にこれが必要だった。10TB 超のデータが入ったハードディスクを NTFS からフォーマットしなければならなかった
    すばらしいプロジェクト

  • LZX 圧縮が適用されたファイルまでサポートしているなら、かなり驚きそう
    Windows 2000 時代のファイル圧縮とは別物で、compact.exe /C /EXE:LZX (filename) で有効化する必要がある機能

  • 以前使ってみたが、結果は読み取り専用ディスクだった。あの時より良くなっていることを願う

  • ここで見える無謀さの度合いはグラフを突き抜けている

    • 思っているほど危険ではない
      標準的なやり方は、古いファイルシステム上に新しいファイルシステムのメタデータ用の大きなファイルを予約し、その後、古いファイルシステムの全ファイルを走査しながら fiemap() で既存データを指す新しいエクステントを作ること。書き込みは予約しておいた領域にだけ行う
      スーパーブロックは最後にだけ上書きし、その前に古いファイルシステムと新しいファイルシステムの内容が同じか検証できる
    • 数年前は、チェーンソーをジャグリングするレベルに近かった: https://github.com/maharmstone/ntfs2btrfs/issues/9
      その頃これを触っていて、かなり厄介なバグをいくつか追跡したので、今はもっと安定していることを願う
    • Apple も HFS+ から APFS へ、同じようなことを実際の OS X/iOS 配布環境で数十億台規模に対してやり遂げた
      他の人が言うように、規模を持って体系的に行うことはできるが、当然ながら注意は必要
    • これは Linux の btrfs ではない
      「WinBtrfs は、次世代 Linux ファイルシステム Btrfs のための Windows ドライバーです。ゼロから再実装されており、Linux カーネルコードは含まず、Windows XP 以降のどのバージョンでも動作するはずです。また、自由オペレーティングシステム ReactOS の一部としても含まれています。」
      この内容は ntfs2btrfs のメンテナーのページから取ったもの
      https://github.com/maharmstone/btrfs
    • インプレースアップグレードで Windows が 2 回壊れるのを見た身としては、素直に新しいディスクかコンピューターを買ってやり直す
      これが別のケースなのは分かっているが、そのデータに費やされた時間は新しいディスクよりはるかに価値がある。個人的にはリスクを取るほどではない。データが重要でないか、バックアップがしっかりあり、バグの発見に貢献したいなら試してもいいかもしれない
  • 本当にすばらしいが、2 年間先延ばしにしていた NTFS ドライブのフォーマットを終えてから少なくとも 1 週間は経って、ようやくこれを知る人が大半な気がする