Btrfs 子卷 UUID 冲突

Question

同一台计算机上具有相同 UUID 的两个文件系统是有问题的，例如。它可能会导致数据损坏，特别是如果两者同时安装（就像BTRFS wiki 所说的那样）。因此，使用例如复制 BTRFS 分区。dd给另一个人并立即使用它是不好的。

为了防止这种情况，
btrfstune -u /dev/sdaX
请更改给定分区的 UUID。

然而，BTRFS 子卷有自己的 UUID，可以查看，例如：和
btrfs sub list -u /mountpoint。
上面的命令不会更改此 UUID，并且显然没有其他方法可以做到这一点。

我的问题是：这是一个类似于主UUID的问题吗？安装两个具有相同子卷 UUID（但主 UUID 不同）的 BTRFS 分区是否会导致数据损坏？

也许我的困惑来自于我不明白它们的用途。文件系统 UUID 必须是唯一的才能识别它，并且可以用于多种用途，例如安装等，但是子卷已经有另一个唯一的编号和名称（在文件系统中是唯一的），并且子卷没有任何（？）除了查看之外，UUID 完全可以从用户 POV 中使用。

...

与此同时，我做了一些测试。具有一些子卷和文件的多个分区，所有分区上的名称部分相同，部分不同。以几乎任何合理的组合查询/创建/删除/移动/读取/修改子卷/文件。不同的主 UUID，相同的子卷 UUID。结果：看不到问题...尽管如此，还是可以保证即使在异常情况下也不会损坏数据，因为 xyz 会很好:)

为了完整起见，正如预期的那样，相同的主UUID 会导致数据损坏，并且它会立即执行此操作，而不仅仅是在异常情况下。内核（或其他东西）会混淆每次访问应该访问哪个分区。大多数情况下，它会转到第一个或最后一个分区（按时间顺序安装），与使用哪个安装点无关。...至少在我的测试中没有“垃圾数据”损坏，但发生的情况已经够糟糕了，特别是如果分区 1 已在使用而分区 2 已安装（从某种意义上说，那么它确实是垃圾）

Answer 1

tldr：没关系，不会有数据损坏。

在邮件列表中也被询问，他们解释说 subvol UUID
只是用于btrfs send和 的健全性检查btrfs receive。

...
子卷上的 UUID 仅在该文件系统内部真正使用，因此内核没有机会感到困惑。可能会混淆的主要问题是发送/接收，但这可能会丢失一些验证（从而允许您执行一些失败的操作），而不是造成主动损坏，如重复 FS-UUID 情况。
...

来自https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg49133.html（原为http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/焦点=50917）

现在我可以睡得更好了:p