linux – Btrfs子卷UUID冲突

在同一台计算机上具有相同UUID的两个文件系统是有问题的,例如.它可能导致数据损坏,特别是如果两者同时安装(如BTRFS wiki says too).因此,使用例如复制BTRFS分区. dd到另一个并立即使用它是坏的.

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

但是,BTRFS子卷具有自己的UUID,可以查看例如.同
btrfs子列表-u / mountpoint.
上面的命令不会更改此UUID,显然没有其他方法可以执行此操作.

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

也许我的困惑来自于我不明白它们的用途.文件系统UUID必须是unqiue才能识别它,并且可以用于安装等几个方面,但是子卷已经有另一个unqiue数字和名称(在文件系统中是唯一的),并且没有什么(？)其中子卷除了查看之外,UUID可以在用户POV中使用.

…

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

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

解决方法:

tldr：没关系,没有可能的数据损坏.

在邮件列表中也被问到,并且他们解释了subvol UUID
只是用于btrfs发送和btrfs接收的健全性检查.

…
The UUIDs on subvols are only
really used internally to that filesystem, so the kernel doesn’t have
a chance to get confused. The main thing that could be confused is
send/receive, but that’s a matter of possibly losing some validation
(thus allowing you to do something that will fail) rather than causing
active damage, as in the duplicate-FS-UUID case.
…

从https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg49133.html(http://thread.gmane.org/gmane.comp.file-systems.btrfs/50909/focus=50917)

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

标签：linux,uuid,btrfs
来源： https://codeday.me/bug/20190813/1649478.html