Btrfs 하위 볼륨 UUID 충돌

예를 들어, 동일한 컴퓨터에 동일한 UUID를 가진 두 개의 파일 시스템이 문제가 있습니다. 특히 두 가지가 동시에 설치된 경우(예:BTRFS 위키는 또한 말한다). 따라서 예를 들어 BTRFS 파티션을 복사하십시오. dd다른 사람에게 주고 바로 사용하는 것은 좋지 않습니다.

이를 방지하려면
btrfstune -u /dev/sdaX
해당 파티션의 UUID를 변경하십시오.

그러나 BTRFS 하위 볼륨에는 볼 수 있는 자체 UUID가 있습니다(예: 및 )
btrfs sub list -u /mountpoint.
위의 명령은 이 UUID를 변경하지 않으며 이를 수행하는 다른 방법은 분명히 없습니다.

내 질문은: 이것이 기본 UUID와 유사한 문제입니까? 동일한 하위 볼륨 UUID(그러나 기본 UUID는 다름)를 사용하여 두 개의 BTRFS 파티션을 마운트하면 데이터가 손상됩니까?

어쩌면 나의 혼란은 그들의 목적을 이해하지 못해서 비롯된 것일 수도 있습니다. 파일 시스템 UUID는 식별을 위해 고유해야 하며 마운트 등 다양한 목적으로 사용할 수 있지만 하위 볼륨에는 이미 다른 고유 번호와 이름(파일 시스템 내에서 고유)이 있고 하위 볼륨에는 ( ?) 보기 외에도 사용자 POV에서 UUID를 완전히 사용할 수 있습니다.

...

그동안 몇 가지 테스트를 해봤습니다. 일부 하위 볼륨과 파일이 있는 다중 파티션, 이름은 모든 파티션에서 부분적으로 동일하고 부분적으로 다릅니다. 거의 모든 합리적인 조합으로 하위 볼륨/파일을 쿼리/생성/삭제/이동/읽기/수정합니다. 다른 기본 UUID, 동일한 하위 볼륨 UUID. 결과: 할 수 없다바라보다질문 하나... 그래도 xyz는 괜찮기 때문에 비정상적인 상황에서도 데이터가 손상되지 않을 것이라는 보장이 있습니다 :)

완전성을 위해 동일기본예상한 대로 UUID는 데이터 손상을 일으키며, 비정상적인 상황뿐만 아니라 즉시 데이터 손상을 유발합니다. 커널(또는 다른 것)은 액세스할 때마다 어느 파티션에 액세스해야 하는지 혼동합니다. 대부분의 경우 어떤 마운트 지점이 사용되는지에 관계없이 첫 번째 또는 마지막 파티션(시간순으로 마운트됨)으로 이동합니다. ...적어도 내 테스트에서는 "정크 데이터" 손상이 없었지만 발생하는 상황은 충분히 나쁩니다. 특히 파티션 1이 이미 사용 중이고 파티션 2가 마운트된 경우(어떤 의미에서는 쓰레기입니다)