使用 btrfs (SLES15) 的非空掛載點:需要它們嗎?

使用 btrfs (SLES15) 的非空掛載點:需要它們嗎?

我有多年的UNIX經驗,但我認為我犯了一個致命的錯誤:

在啟動過程中看到有關非空掛載點的訊息後,我趁機將系統遷移到新環境時清理了它們。我啟動了 SLES Rescue System,在 上安裝了根檔案系統和基本系統結構(proc、sys、dev)/mnt,然後執行了chroot /mntmount -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/root包含 Btrfs 檔案系統。您的多個條目fstab將其不同的子磁碟區安裝到不同的安裝點。

假設:Btrfs 檔案系統中的預設子磁碟區/dev/sys/root/@,一旦安裝在/,就會安裝許多其他子磁碟區在其特定的安裝點幾乎沒有任何意義,因為正確的(通常非空的)目錄已經在您期望的位置了。

(若要查看預設子卷,請執行sudo btrfs subvolume get-default /。)

請閱讀這是我的另一個答案並了解裝置上的 Btrfs 目錄(和子磁碟區)樹與作業系統中的目錄結構之間的概念差異。如果沒有這些知識,目前答案的其餘部分可能會讓您感到非常困惑。

如果預設子磁碟區是/@/@來自 Btrfs 樹的顯示與/作業系統樹中一樣以及下面的一切。這個安裝獨自的足以查看/@/varBtrfs 樹中的目錄(如/var作業系統樹中的目錄)。我的意思是如果你嘗試訪問/var /var然後安裝

  • 作業系統將檢查/var(作業系統的)是否為掛載點;它不是;
  • 因此作業系統將檢查/(作業系統的)是否為掛載點;它是並且與/@Btrfs 相關聯;
  • 因此作業系統將向您顯示作業系統的/@/varBtrfs 。/var

碰巧/@/varBtrfs 是一個子卷。另外安裝subvol=/@/var/var(作業系統)將使與/var(作業系統)出現相同的目錄。具體來說,如果您現在/var訪問

  • 作業系統將檢查/var(作業系統的)是否為掛載點;它是並且與/@/varBtrfs 相關聯;
  • 這樣作業系統就會向您顯示/@/varBtrfs。

如果您卸載/var(作業系統),那麼您將回到第一種情況。

因此,(作業系統的)是否安裝並不重要/var(實際上並不重要,可能存在微妙之處)。無論怎樣,您都會像在作業系統中一樣看到/@/varBtrfs 。/var

fstab掛載不同子磁碟區中的其他幾個條目無論如何你都會在哪裡看到他們。我真的不明白這些條目的意義(我目前無法識別的一些微妙之處可能是重點;或者這些條目確實完全沒有意義)。

作為比較:如果/var(作業系統的)已安裝,subvol=/var則安裝是有意義的,因為/varBtrfs 不在/@Btrfs 之下,因此您無法僅透過安裝作業系統/@的 Btrfs來存取它。/


你是如何打破它的

...已安裝,umount成功,但仍ll …顯示非空安裝點,而檔案系統顯示未安裝。所以我刪除了內容。

正如我所說,您的多個條目fstab安裝了不同的子卷,您無論如何都會看到它們。在這些情況下,請在umount刪除之前看到的內容後刪除內容umount。您以為您刪除了隱藏的、不相關的內容,但實際上您刪除了實際的、重要的內容。

但有兩點不適合:

  1. 您的範例掛載點是/var/cache,據稱您已卸載它;但你發的貼文/var/cache裡沒有fstab
  2. 根據您fstab發布的內容,雖然/(作業系統的)來自/dev/sys/root/boot(作業系統的)來自/dev/sys/boot。所描述的破壞事物的機制不適用。然而你聲稱“GRUB 抱怨它找不到normal.mod”,由此我推斷你確實以/boot某種方式破壞了東西。

因此,我懷疑已發布的內容fstab(您將其描述為“典型系統所具有的內容”)並不是精確的 fstab受影響的作業系統。我懷疑/boot使用了與 相同的檔案系統/,但沒有必要安裝,因此容易出現所描述的破壞情況。

相關內容