Btrfs 子卷 UUID 衝突
在同一台電腦上具有相同 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 會導致數據損壞，並且它會立即執行此操作，而不僅僅是在異常情況下。核心（或其他東西）混淆了每個訪問應該訪問哪個分區。大多數情況下，它會進入第一個或最後一個分區（按時間安裝順序），與使用哪個安裝點無關。…至少在我的測試中沒有“垃圾數據”損壞，但發生的事情已經夠糟糕了，特別是如果分區 2 掛載時分區 1 已經在使用中（從某種意義上說，它確實是垃圾）
tldr：沒關係，沒有可能的數據損壞。
在郵件列表中也被問到，他們解釋說 subvol UUID
只是用於
btrfs send和btrfs receive.…
subvols 上的 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