Btrfsサブボリュームの問題

Btrfsサブボリュームの問題

Btrfsに関するいくつかの質問:

  1. サブボリュームを作成する前にBtrfsファイルシステムをマウントする必要がありますか?
  2. 既存のディレクトリをサブボリュームに簡単に変換できますか? (つまり、「/home」を別のサブボリュームにしたい場合は、mk_btrfs_subfolder /home新しい空のサブボリュームを作成し、すべてのエントリをコピーすることなく直接(またはコマンドが何でも)実行できますか?

上記のタスクを実行するコマンドは良いですが、必須ではありません。はい/いいえの場合はOKで、Googleでこれを行う方法を検索できます。

答え1

はい、インストールする必要があり、ディレクトリをサブボリュームに変換するには、次のようにスナップショットを作成できます。

btrfs subvolume snapshot <name of subvolume containing folder> @new_subvol

その後、サブボリュームに移動して@new_subvol / homeを除くすべてのエントリを削除し、自宅のすべてのエントリを新しいサブボリュームのルートに移動できます。

mv @new_subvol/home/* @new_subvol

その後、元のディレクトリを削除し、新しく作成されたスナップショットをその場所に移動できます。

答え2

  1. はい。
  2. いいえ。

少なくともまだではありません。


答え3

既存のディレクトリをサブボリュームに簡単に変換できますか? (つまり、「/home」を別のサブボリュームにしたい場合は、新しい空のサブボリュームを作成し、すべてをコピーすることなくmk_btrfs_subfolder /home(または他のコマンド)に移動できますか?

大規模なサブボリュームの場合、最も悪いアプローチは、サブボリュームをスナップショットとして作成してクリーンアップすることです。これにより、実際にファイルデータのコピーを防ぐことができますが、デフォルトでサポートされている場合は、不要なメタデータ更新が大量に発生します。

Andrewは彼の答えでこれを言及しましたが、完全な例を提供していないので、ここに1つあります。私は彼とは少し異なるアプローチをとり、最後の場所にサブボリュームを作成できるように、以前のディレクトリを最初に移動しました。

cd /build/
mkdir xxxx
mv *-rpi-staging xxxx
btrfs subvolume snapshot /build /build/wheezy-armhf-rpi-staging
btrfs subvolume snapshot /build /build/jessie-armhf-rpi-staging
btrfs subvolume snapshot /build /build/stretch-armhf-rpi-staging
btrfs subvolume snapshot /build /build/buster-armhf-rpi-staging
cd /build/wheezy-armhf-rpi-staging/
find -maxdepth 1 ! -name xxxx ! -name . -exec rm -rf {} +
(shopt -s dotglob; mv -- xxxx/wheezy-armhf-rpi-staging/* . )
rm -rf xxxx
cd /build/jessie-armhf-rpi-staging/
find -maxdepth 1 ! -name xxxx ! -name . -exec rm -rf {} +
(shopt -s dotglob; mv -- xxxx/jessie-armhf-rpi-staging/* . )
rm -rf xxxx
cd /build/stretch-armhf-rpi-staging/
find -maxdepth 1 ! -name xxxx ! -name . -exec rm -rf {} +
(shopt -s dotglob; mv -- xxxx/stretch-armhf-rpi-staging/* . )
rm -rf xxxx
cd /build/buster-armhf-rpi-staging/
find -maxdepth 1 ! -name xxxx ! -name . -exec rm -rf {} +
(shopt -s dotglob; mv -- xxxx/buster-armhf-rpi-staging/* . )
rm -rf xxxx

これはタスクの例に関する注意事項です。

  1. / buildはbtrfsファイルシステムです。
  2. wheezy-armhf-rpi-staging jessie-armhf-rpi-stagingstretch-armhf-rpi-stagingとbuster-armhf-rpi-stagingは変換するディレクトリです。
  3. この例は、私が実際に行ったことをまとめたバージョンです。間違いがある場合はご指摘ください。
  4. xxxxというファイル/ディレクトリは、変換中のディレクトリのすぐ下に、または変換中の最上位ディレクトリの直下に存在してはいけません。
  5. 機密データを含むシステムでこれを行う場合は、問題が発生した場合に復元できるように、最初に追加のスナップショットを作成することをお勧めします。
  6. 使用されるシェルはbashであると仮定します。

答え4

既存のディレクトリをサブボリュームに簡単に変換できますか? (つまり、「/home」を別のサブボリュームにしたい場合は、新しい空のサブボリュームを作成し、すべてをコピーすることなくmk_btrfs_subfolder /home(または他のコマンド)に移動できますか?

私はこの問題の特定のバージョンに直面しました。私のファイルシステムには、snapperというユーティリティによって特定のスケジュールに従ってスナップショットが作成された複数のトップレベルbtrfsサブボリュームがありました。残念ながら、頻繁に変更されるディレクトリの場合、これによりかなり膨らむことが生じることがありますが、その中から除外したいことが多いです。

初期設定では、スナップショットから特定のパスを除外するのは簡単です。関連パスに新しいbtrfsサブボリュームを作成するだけです。残念ながら、実行中のシステムがあると、状況は少し複雑になります。

アイデアスクリプトの作成は難しくなく、小さなbashスクリプトから始めました。もちろん、さまざまなタイプの入力、ファイルロック、権限などを扱い始め、この小さなスクリプトはほぼ100行に急速に増加しました。

同様の問題がある場合(Snapper管理btrfsファイルシステムをクリーンアップしたい場合)、以下を使用することをお勧めします(責任は自分の負担です)。https://github.com/billwanjohi/snapper-exclude/blob/master/snapper-exclude.sh

関連情報