最初的问题
因此，我将新 BTRFS 池的子卷安装为/home.我以为在重新格式化旧驱动器以添加到池中之前我已经将所有内容复制到其中，但在后来的检查中，一些文件（我的所有多媒体）丢失了。我听天由命，开始重建藏品。
后来，我运行了内置的“Baobob”磁盘使用实用程序。它显示的内容/mnt/wd比预期更多。我看得更仔细了。仍然保留着我所有“丢失”的文件（而不是我搬迁后/mnt/wd/home/$USER/multimedia放入的文件）（BTRFS 系统的根目录有 label ）。~/multimediawd
回头一看~/multimedia，旧的文件已经不在了，新的文件还在。
丢失文件之间的共性
最初丢失的文件有一个共同点。在复制到新驱动器之前，未丢失的文件位于ext4安装为/home.所做的全部位于ntfs旧驱动器的分区上，安装为/media/$USER/data，符号链接从 指向它们/home/$USER。那是为了适应双启动，但我已经停止使用了。将所有内容复制到新卷时（使用rsync，以防相关），我将所有文件放在一个子卷中，而不是拆分它们并进行符号链接（在两个目录完成mv后，将一个目录的内容复制到另一个目录中）。rsync在确定这个结果之前，我确实对子目录进行了一番摆弄，但我最终只得到了我所能知道的最好的一个子卷。在将新子卷安装为 之前/home，这似乎有效。之后，来自的视图/home似乎与原始/home分区匹配，并且来自的视图/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
/mnt/wd我还通过挂载了 BTRFS 卷的根目录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（以及任何其他丢失的目录）在从/home或从运行时显示完全不同的内容/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/安装实验：
我尝试在我的 fstab 中安装 BTRFS 根目录/mnt/wd（行是 ，放置在该/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（注释行 out）。然后，当我取消注释该行并安装时/home，生成的安装驱动器/mnt/wd与旧文件而不是新文件匹配。所以我认为这可能会在启动时变得不稳定？
“未更改”的文件仍然存在分歧
文件系统仍在单独跟踪两个版本之间未丢失的文件。我分别看了tail .bash_history一遍，发现它们各有不同。
问题出在安装点和子卷的组合上吗？
我将home子卷安装在/mnt/foo（并稍后在/foo）而不是 处重试/home。它与旧版本匹配。我制作了子卷的快照home，将其命名为newhome，并将其安装在/home。它与新版本匹配（缺少旧文件，显示新文件）。
我将一个新文件添加到仅在新版本中的目录之一（仍在 中newhome）。我改回安装home并/home重新启动。文件不见了。改回 using newhome，文件仍然存在。以其他顺序执行相同的操作（将其放入版本home并检查newhome），并将文件放入没有不同的目录之一。结果是相同的 - 文件仅存在于它所放入的子卷中，并且仅存在于新版本中（仅在安装为 时出现/home，但每个版本都不同）。这排除了我的最新想法，即它将“安装在/home安装点的子卷”视为与我实际安装的任何子卷不同的东西，无论出于何种原因。
我获取了一个不相关的子卷，为我的用户名添加了一个子目录，并将其安装在/home.结果是操作系统仍然识别我的用户名/密码，但重新生成了其中的所有配置文件和目录，就好像我是新用户一样 - 它没有使用“新版本”的分区/home。
我想现在我可以总结一下情况了。这并不能帮助我解决问题或确定原因。
太长了；博士
名为“home”的子卷及其派生的快照实际上是两个子卷，其中一个仅在挂载为 时出现/home，另一个在挂载到其他位置或作为 BTRFS 设备根卷的子目录可见时出现 -水池。由于未知的原因，两者在不晚于我第一次将其安装为 时在某个时刻出现了分歧/home，因此安装的版本包含我已通过 -ed 覆盖的/home旧分区的内容，而安装在其他任何位置的版本包含文件系统因为我在初始之后对其进行了修改（用先前链接的文件替换了到另一个分区的几个符号链接）。/homersyncrsync
我不知道为什么会这样。我可以确认，当不是从“home”派生的子卷安装为 且没有复制来自“home”的文件时，不会发生这种情况/home。我可以确认，将一小部分文件复制到新子卷时，确实会发生这种情况。我现在将测试复制所有文件，而cp不是制作快照。
这很有效，但有一个棘手的地方可能指出了问题所在。当我尝试cp -a --reflink=always ./*从新/home/qwertystop的主子卷开始时，每个文件都收到一条错误消息：“跨设备链接无效。”当运行相对于 的相同命令时，不会出现这种情况/mnt/wd/home/qwertystop。该问题似乎是由计算机将一个安装位置读取为与另一个安装位置不同的设备引起的、由其引起的或以其他方式与之相关。我认为这在技术上是可行的——它是三个不同设备的 BTRFS 池。
当我切换到复制版本时/mnt/wd/home，它最初似乎可以工作，但少量使用很快发现新子卷中出现的重复与旧子卷中的相同。
答案1
我已经解决了这个问题，尽管没有解决为什么这是一个问题或最初的分歧来自哪里的相关问题。
当我将主目录复制到新的子卷，但没有复制 /home/.ecryptfs 时，复制停止。因此，重复似乎是由 .ecryptfs 引起的。我不确定这是否是一个错误，或者是我不知道的某些系统的预期行为。
请注意，您已禁用系统安装时使用的加密。
ecryptfs 是一个堆栈文件系统。它可以在登录时安装 - 即在用户输入密码时安装，他们想用该密码加密数据。 findmnt（或）将显示安装在 处的mount文件系统类型。写入的文件由 ecryptfs 加密，然后存储在（即 btrfs）中的某个位置。这只是一种可能的 ecryptfs 设置；还可以采用其他方式进行安排。ecryptfs/home/$USER/home/$USER//home/.ecryptfs/$USER/
请不要挑剔上面的描述，因为我从未使用过它。您可以在此处找到社区提供的文档：
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 快照时使用该帐户。
答案2
我已经解决了这个问题，尽管没有解决为什么这是一个问题或最初的分歧来自哪里的相关问题。
当我将主目录复制到新的子卷，但没有复制时/home/.ecryptfs，复制停止了。因此，重复似乎是由某种原因引起的.ecryptfs。我不确定这是否是一个错误，或者是我不知道的某些系统的预期行为。