最初的問題

因此，我將新 BTRFS 池的子卷安裝為/home. 我以為我在重新格式化舊驅動器以添加到池之前已將所有內容複製到其中，但在後來的檢查中，一些文件（我所有的多媒體）失去了。我辭職去重建收藏。

後來，我執行了內置的“Baobob”磁碟使用實用程序。它顯示的內容/mnt/wd比預期的要多。我更仔細地看了看。/mnt/wd/home/$USER/multimedia仍然有我所有的“失去”文件（而不是我~/multimedia搬家後放入的文件）（BTRFS 系統的根目錄有 label wd）。

回頭看~/multimedia，舊文件不在，新文件還在。

---

失去文件之間的共性

最初失去的文件有一個共同點。在被複製到新驅動器之前，沒有失去的文件位於ext4以/home. 那些都在ntfs舊驅動器的一個分區上，掛載為/media/$USER/data，符號連結從/home/$USER. 那是為了適應我已經停止使用的雙引導。將所有內容複製到新卷時（使用rsync，以防相關），我將所有文件放在一個子卷中，而不是將它們拆分並符號連結（mv將一個目錄的內容連結到另一個目錄，在兩者之後rsyncs 已完成）。在確定該結果之前，我確實對子目錄進行了一些擺弄，但我最終只得到了一個子卷，盡我所能。在將新的子卷掛載為 之前/home，這似乎可行。之後，view from/home似乎與原始/home分區匹配，view from/mnt/wd/home似乎與合併版本匹配。

---

初始配置/狀態

我fstab此時是：

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p5 during installation
UUID=699ad207-3b40-4caa-9926-503830121327 /               ext4    errors=remount-ro 0       1
# BTRFS pool
UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05   /home   btrfs   defaults,autodefrag,subvol=home 0   2
UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05   /mnt/app_drive  btrfs   defaults,autodefrag,subvol=applications 0   2
UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05   /mnt/snapshots  btrfs   defaults,autodefrag,subvol=snapshots    0   2
# Swap file
/swapfile1 none swap sw 0 0

我還將 BTRFS 卷的根目錄掛載為/mnt/wdvia sudo mount UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05 /mnt/wd。

sudo btrfs subvolume list .從任何子卷（或根）的任何安裝位置執行：

ID 638 gen 4492 top level 5 path home
ID 639 gen 4433 top level 5 path applications
ID 640 gen 4404 top level 5 path snapshots
ID 800 gen 4402 top level 640 path snapshots/home_2017-07-06

但是ls ./$USER/multimedia（以及任何其他缺失的目錄）在 from/home或 from執行時顯示完全不同的內容/mnt/wd/home。

qwertystop@dt /home $ ls $USER/multimedia
pics  unprepared
qwertystop@dt /home $ cd /mnt/wd/home
qwertystop@dt /mnt/wd/home $ ls $USER/multimedia
3d  ml_resource  music  osu!  phone-ready  pics  Unprepared  vids

有沒有人知道這裡發生了什麼，或者我如何調和這兩者？我的想法是將所有內容從一個複製到另一個 - 但這仍然意味著我必須確保為每個新文件都這樣做，最好的情況。

---

進一步的實驗

快照

我嘗試製作快照。無論我使用哪個掛載點來創建快照，也無論我把它放在哪裡，它始終與 中找到的版本匹配/mnt/wd/home，而不是/home. 我試過了：

sudo btrfs subvolume snapshot /home /home/snapshot
sudo btrfs subvolume snapshot /mnt/wd/home /mnt/snapshots/snapshot
sudo btrfs subvolume snapshot /home /mnt/snapshots/snapshot

而且它們都是相同的。這是內部一致性的一個優點，但它沒有告訴我為什麼當我嘗試訪問任何文件時不一致仍然存在。

---

fstab/安裝實驗：

我嘗試/mnt/wd在我的 fstab 中安裝 BTRFS 根目錄（行是 ，放置/home在行之前），而不是使用mount. 我fstab此時是：

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p5 during installation
UUID=699ad207-3b40-4caa-9926-503830121327 /               ext4    errors=remount-ro 0       1
# BTRFS pool
UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05   /mnt/wd   btrfs   defaults,autodefrag 0   2
UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05   /home   btrfs   defaults,autodefrag,subvol=home 0   2
UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05   /mnt/app_drive  btrfs   defaults,autodefrag,subvol=applications 0   2
UUID=24f6bbb6-cccb-4f12-808c-195f18b19e05   /mnt/snapshots  btrfs   defaults,autodefrag,subvol=snapshots    0   2
# Swap file
/swapfile1 none swap sw 0 0

這沒有產生任何變化。

我嘗試過根本不安裝主子卷（註釋掉行）。然後，當我取消註釋該行並安裝時，生成的安裝驅動器與舊文件匹配，而不是新文件。所以我認為這可能會在啟動時出現問題？/home``fstab``/home``/mnt/wd

“未更改”文件仍然存在分歧

兩個版本之間沒有失去的文件仍然由文件系統單獨跟踪。我看了tail .bash_history每一個，它們都不一樣。

問題在於安裝點和子卷的組合？

我將子卷安裝home在/mnt/foo（並在稍後重試/foo）而不是/home. 它與舊版本相匹配。我製作了子卷的快照，將home其命名為newhome，並將其安裝在/home. 它匹配新版本（失去舊文件，呈現新文件）。

我將一個新文件添加到僅在新版本中（仍在newhome）中的目錄之一。我改回安裝home在/home並重新啟動。文件不見了。改回 using newhome，文件仍然存在。以其他順序執行相同操作（將其放入homeversion 並檢查newhome），並將文件放入沒有不同的目錄之一。結果是一樣的——文件只存在於它被放入的子卷中，並且只存在於新版本中（僅在掛載為時出現/home，但每個版本都不一樣）。這排除了我的最新想法，即/home無論出於何種原因，它將“安裝在安裝點的子卷”視為與我實際安裝的任何子卷不同的東西。

我拿了一個不相關的子卷，為我的使用者名添加了一個子目錄，並將其安裝在/home. 結果是作業系統仍然辨識出我的使用者名/密碼，但重新生成了其中的所有配置文件和目錄，就好像我是一個新使用者一樣——它沒有/home使用分區的“新版本” 。

我想在這一點上我可以總結一下情況。這不能幫助我解決問題或確定原因。

tl;博士

名為“home”的子卷及其派生的快照實際上是兩個子卷，其中一個僅在掛載為 時出現/home，另一個在掛載到其他位置或作為 BTRFS 設備的根卷的子目錄可見時出現-水池。出於未知原因，兩者在不遲於我第一次將其掛載為 時發生了分歧，因此/home掛載的版本/home包含我已經 -ed 的舊/home分區的內容rsync，而掛載在其他任何地方的版本包含文件系統因為我在初始之後修改了它rsync（用之前連結的文件替換了幾個符號連結到另一個分區）。

我不知道為什麼會這樣。我可以確認，當不從“home”派生的子卷掛載為 時，不會發生這種情況/home，並且沒有複製“home”中的文件。我可以確認它確實發生在將一小部分文件複製到新子卷的情況下。我現在將測試複製所有文件，cp而不是製作快照。

這很奏效，但有一點可能會指出問題所在。當我嘗試cp -a --reflink=always ./*從新/home/qwertystop的主子卷轉換時，每個文件都收到一條錯誤消息：“跨設備連結無效。” 相對於 執行相同的命令時，這沒有出現/mnt/wd/home/qwertystop。**問題似乎是由電腦將一個安裝位置讀取為與另一個安裝位置位於不同的設備上引起的、由其引起或以其他方式相關的。**我想，這在技術上是可行的——它是由三個不同設備組成的 BTRFS 池。

當我切換到從/mnt/wd/home版本中複製出來時，它最初似乎可以工作，但輕量級的使用很快發現重複出現在新的子卷中和舊的子卷中一樣。

我已經解決了這個問題，儘管沒有解決為什麼它是一個問題或最初的分歧來自哪裡的相關問題。

當我將我的主目錄複製到一個新的子卷，但沒有複製 /home/.ecryptfs 時，複製停止了。因此，重複似乎是由 .ecryptfs 以某種方式引起的。我不確定這是否是我不知道的某些系統的錯誤或預期行為。

請注意，您已禁用安裝系統的加密。

ecryptfs 是一個堆疊文件系統。它可以在登錄時安裝 - 即在使用者輸入他們想要加密數據的密碼時。 findmnt（或mount）將顯示ecryptfs安裝在的類型的文件系統/home/$USER。寫入的文件/home/$USER/由 ecryptfs 加密，然後儲存在某個位置/home/.ecryptfs/$USER/（即 btrfs）。這只是一種可能的 ecryptfs 設置；還有其他的安排方式。

請不要挑剔以上描述，因為我從未使用過它。您可以在此處找到社區提供的文件：

https://help.ubuntu.com/community/EncryptedHome#Encrypted_Home

這應該可以解釋為什麼當您使用安裝在 的 btrfs 卷登錄/home並查看您的主目錄時看到一些不同的文件，與安裝在時在相同 btrfs 卷/home/$USER的目錄中看到的文件相比。$USER/``/mnt

“無效的跨設備連結。” 執行與 /mnt/wd/home/qwertystop 相關的相同命令時，不會出現這種情況。問題似乎是由電腦將一個安裝位置讀取為與另一個安裝位置位於不同的設備上引起的、由其引起或以其他方式相關的。

恐怕“跨設備連結”是用詞不當。它實際上是一個跨文件系統連結。您不能將 btrfs 文件系統中的文件硬連結或引用連結到 ecryptfs 文件系統，反之亦然。

我嘗試製作快照。無論我使用哪個掛載點來創建快照，無論我把它放在哪裡，它總是與 /mnt/wd/home 中的版本匹配

您現在應該也可以看到這是如何發生的。

警告：在您仍然登錄並安裝 ecryptfs 時恢復快照或以其他方式弄亂備份儲存，聽起來非常令人擔憂。相反，您可以啟用 root 使用者或使用未加密的主目錄創建一個特殊的管理員使用者帳戶，並在需要恢復 /home 的快照時使用它。

引用自：https://unix.stackexchange.com/questions/375894