BtrfsサブボリュームUUIDの競合

たとえば、同じコンピュータに同じUUIDを持つ2つのファイルシステムに問題があります。特に2つが同時にインストールされている場合（例：BTRFS Wikiはまた言う）。したがって、たとえば、BTRFSパーティションをコピーします。dd他の人に与えてすぐに使用するのは良いことではありません。

これを防ぐには、
btrfstune -u /dev/sdaX
そのパーティションのUUIDを変更してください。

ただし、BTRFSサブボリュームには、表示できる独自のUUIDがあります（たとえば、および）
btrfs sub list -u /mountpoint。
上記のコマンドはこのUUIDを変更せず、これを行う他の方法は明らかではありません。

私の質問は：これがデフォルトのUUIDと同様の問題ですか？同じサブボリュームUUID（ただしデフォルトのUUIDは異なる）を使用して2つのBTRFSパーティションをマウントすると、データが破損しますか？

おそらく私の混乱は彼らの目的を理解していないので、それが原因であるかもしれません。ファイルシステムUUIDは識別のために一意である必要があり、マウントなどのさまざまな目的で使用できますが、サブボリュームにはすでに別の固有番号と名前（ファイルシステム内で一意）があり、サブボリュームには（？）ビューに加えて、ユーザーPOVからUUIDを完全に使用できます。

...

これまでいくつかのテストをしてみました。一部のサブボリュームとファイルがあるマルチパーティション、名前はすべてのパーティションで部分的に同じで部分的に異なります。ほぼすべての合理的な組み合わせで、サブボリューム/ファイルをクエリ/作成/削除/移動/読み取り/変更します。異なるプライマリUUID、同じサブボリュームUUID。結果：できませんバラより質問一つ...でもxyzは大丈夫なので、異常な状況でもデータが破損しないという保証があります:)

完全性のために同じ基本予想通り、UUIDはデータの破損を引き起こし、異常な状況だけでなくデータの破損を即座に引き起こします。カーネル（または他のもの）は、アクセスするたびにどのパーティションにアクセスする必要があるかを混同します。ほとんどの場合、どのマウントポイントが使用されているかにかかわらず、最初または最後のパーティション（時系列でマウント）に移動します。 ...少なくとも私のテストでは「ジャンクデータ」の破損はありませんでしたが、発生する状況は十分に悪いです。特に、パーティション1がすでに使用されていてパーティション2がマウントされている場合（ある意味、ごみです）