☰

btrfs を使用した空でないマウント ポイント (SLES15): それらは必要ですか?

tag-icon • tag-icon mount btrfs suse
btrfs を使用した空でないマウント ポイント (SLES15): それらは必要ですか?

私は長年の UNIX 経験がありますが、致命的なミスを犯したと思います。

起動中に空でないマウント ポイントに関するメッセージが表示されたので、システムを新しい環境に移行するときにそれらをクリーンアップすることにしました。SLES Rescue System を起動し、ルート ファイル システムと基本システム構造 (proc、sys、dev) を にマウントし/mnt、chroot /mntと を実行しましたmount -va。

すべてがうまくいったので、いくつかの構成設定を調整し、アンマウント中にマウント ポイントを確認しました。たとえば、 /var/cacheマウントはumount成功しましたが、ll /var/cache空でないマウント ポイントが表示され、ファイルシステムはマウントされていないと表示されました。そのため、コンテンツを削除しました。

基本的に、マウントされたすべてのファイルシステムに対して手順を繰り返し、chroot環境を終了し、残りをアンマウントして再起動しました。

残念ながら、GRUB が見つからないと報告したため、システムは起動しませんnormal.mod。

これは btrfs サブボリュームの機能ですか? 何が起こっていたのか説明できる人はいますか?

/etc/fstab

求められたとおり/etc/fstab、典型的なシステムは次のとおりです。

/dev/sys/root                              /            btrfs  defaults              0  0
/dev/sys/root                              /var         btrfs  subvol=/@/var         0  0
/dev/sys/root                              /usr/local   btrfs  subvol=/@/usr/local   0  0
/dev/sys/root                              /tmp         btrfs  subvol=/@/tmp         0  0
/dev/sys/root                              /srv         btrfs  subvol=/@/srv         0  0
/dev/sys/root                              /root        btrfs  subvol=/@/root        0  0
/dev/sys/root                              /opt         btrfs  subvol=/@/opt         0  0
UUID=9fd27493-d194-48ba-a4bc-3551123e0d3b  /home        xfs    defaults              0  0
/dev/sys/boot                              /boot        btrfs  defaults              0  0
UUID=0092-D1D5                             /boot/efi    vfat   utf8                  0  2
/dev/sys/root                              /.snapshots  btrfs  subvol=/@/.snapshots  0  0

答え1

仕組み

/dev/sys/rootBtrfs ファイルシステムが含まれています。 内の複数のエントリが、fstabその異なるサブボリュームを異なるマウントポイントにマウントします。

仮説: のBtrfsファイルシステムのデフォルトのサブボリュームは で/dev/sys/rootあり/@、 にマウントされると/、他の多くのサブボリュームがマウントされる。それぞれのマウントポイントで適切な (通常は空ではない) ディレクトリがすでに予想される場所にあるため、ほとんど意味がありません。

(デフォルトのサブボリュームを確認するには、 を実行しますsudo btrfs subvolume get-default /。)

読んでくださいこれは私のもう一つの答えですまた、デバイス上の Btrfs ディレクトリ (およびサブボリューム) ツリーと OS のディレクトリ構造の概念的な違いを理解してください。この知識がないと、現在の回答の残りの部分は非常にわかりにくいものになる可能性があります。

デフォルトのサブボリュームが/@/@BtrfsツリーからOS/ツリーに表示される下にあるものすべてとともにこのマウント一人で/@/var例えばBtrfsツリーのディレクトリを/varOSツリーのように見るには十分です。つまり、アクセスしようとすると/var 前に /varマウントされると

  • OS は/var(OS の) がマウントポイントであるかどうかを確認しますが、そうではありません。
  • そのため、OS は/(OS の) がマウントポイントであるかどうかを確認します。マウントポイントであり、/@Btrfs に関連付けられています。
  • そのため、OS はOS の/@/varBtrfsを表示します。/var

たまたま/@/varBtrfs はサブボリュームです。さらに（OSの）subvol=/@/varにマウントすると、（OSの）と同じディレクトリが表示されます。具体的には、現在アクセスすると、/var/var/var

  • OS は/var(OS の) がマウントポイントであるかどうかを確認します。マウントポイントであり、/@/varBtrfs に関連付けられています。
  • OS は/@/varBtrfs を表示します。

そして、（OS を）アンマウントすると/var、最初のケースに戻ります。

したがって、(OS の) がマウントされているかどうかは問題ではありません(実質的には問題ではありませんが、微妙な違いがある可能性があります)。いずれにしても、OS 内のBtrfs が/var表示されます。/@/var/var

fstabマウントされた異なるサブボリューム内の他のいくつかのエントリいずれにしてもどこで見られるかこれらのエントリのポイントがよくわかりません (現時点では特定できない微妙な点がポイントなのかもしれません。あるいは、これらのエントリはまったく無意味なのかもしれません)。

比較すると、/var(OS の) がマウントされている場合、 Btrfs は Btrfs の下にはないため、 OSとして Btrfs をマウントするだけではアクセスできないため、subvol=/varマウントすることは意味があります。/var/@/@/

どうやって壊したのか

… マウントされ、umount成功しましたが、ll …ファイルシステムがマウントされていないと表示され、空でないマウントポイントが表示されました。そのため、コンテンツを削除しました。

前述したように、fstabマウントされた複数のエントリは、いずれにしても表示される異なるサブボリュームにあります。これらのケースでは、以前に表示されていたコンテンツを削除した後にコンテンツを削除します。影になった無関係なコンテンツを削除したとumount思っumountていましたが、実際には実際の重要なコンテンツを削除しました。

ただし、適合しない点が 2 つあります。

  1. 例のマウントポイントは です。これをアンマウントしたようですが、投稿した には/var/cacheがありません。/var/cachefstab
  2. あなたが投稿した によるfstabと、/(OS の) は から来ているのに対し/dev/sys/root、/boot(OS の) は から来ています/dev/sys/boot。 記述されている破壊メカニズムは適用できません。 しかし、あなたは「GRUB が を見つけられないと文句を言ったnormal.mod」と主張しており、このことから、何らかの方法で の下で破壊したと推測します/boot。

したがって、公開されているものfstab（あなたが「典型的なシステムが持っているもの」と表現したもの）は、ちょうど fstab影響を受ける OS の。/bootと同じファイルシステムが使用されており/、不必要にマウントされたため、前述のような破損のシナリオが発生しやすいのではないかと思われます。

関連情報