☰

호스트와 동일한 UUID를 가진 btrfs 파티션에 연결된 디스크가 마운트 목록을 손상시키는 것을 방지하는 방법은 무엇입니까?

tag-icon • tag-icon linux filesystems btrfs
호스트와 동일한 UUID를 가진 btrfs 파티션에 연결된 디스크가 마운트 목록을 손상시키는 것을 방지하는 방법은 무엇입니까?

배경: 호스트 OS는 Azure Oracle Linux 7.8 인스턴스이고 해당 OS 디스크는 /dev/sda항목을 통해 탑재됩니다. /dev/sda2( /) 예 btrfs. 다른 Azure Oracle Linux 7.8 인스턴스가 손상되어 디버깅을 위해 해당 디스크를 연결하고 싶습니다. 내 호스트 OS에 연결한 후 연결된 디스크는 동일한 Oracle Linux 7.8 이미지에서 왔기 때문에 내 호스트와 동일한 UUID를 가지며 설치 시 약간의 혼란/손상을 일으키는 것 같습니다. lsblkAzure가 이미지 연결을 마친 후의 출력은 다음과 같습니다 .

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb       8:16   0    4G  0 disk
└─sdb1    8:17   0    4G  0 part /mnt
sr0      11:0    1  628K  0 rom
fd0       2:0    1    4K  0 disk
sdc       8:32   0   50G  0 disk
├─sdc15   8:47   0  495M  0 part
├─sdc2    8:34   0   49G  0 part /      <--- isn't really sdc2, its mounted from sda2
├─sdc14   8:46   0    4M  0 part
└─sdc1    8:33   0  500M  0 part
sda       8:0    0  100G  0 disk
├─sda2    8:2    0   99G  0 part
├─sda14   8:14   0    4M  0 part
├─sda15   8:15   0  495M  0 part /boot/efi
└─sda1    8:1    0  500M  0 part /boot

/루트 가 마운트된 것처럼 보이지만 실제로는 /dev/sdc2디스크( )가 붙어 있는 것을 볼 수 있습니다 . UUID 충돌로 인해 이 문제가 발생했다고 가정할 수 있지만(다른 원인일 수 있습니까?) 이제는 시스템이 이미 마운트되어 있다고 생각하기 때문에 /dev/sdc실제/연결된 디스크를 마운트하여 디버깅할 수 없습니다 ./dev/sdc2

디스크를 연결할 때 이런 일이 발생하지 않도록 하는 방법이 있나요?

답변1

btrfstune디스크를 마운트하기 전에(또는 먼저 마운트 해제하기 전에) btrfs UUID를 변경할 수 있습니다.

# first show the existing UUID (and keep for later)
sudo blkid /dev/sdc2

# change to a new UUID
sudo btrfstune -M $(uuidgen) /dev/sdc2

도 참조하세요 -U. 하지만 -M충분할 것입니다. 나중에 동일한 방법을 사용하여 원래 uuid(uuidgen 대신)를 복원할 수 있습니다.

이 작업을 시도하기 전에 백업을 만드십시오.

답변2

나는 이것이 불가능하다고 생각한다. 중복된 UUID가 있는 여러 BTRFS 파일 시스템이 시스템에 존재하는 경우 데이터 손상 위험 없이 사용할 수 없습니다.https://btrfs.wiki.kernel.org/index.php/Gotchas

먼저 하나의 장치를 숨겨야 합니다(예: SCSI에서 제거). echo 1 > /sys/block/sde/device/delete다른 장치의 UUID를 변경한 다음 첫 번째 장치를 복원해야 echo "- - -" > /sys/class/scsi_host/host0/scan 하지만 BTRFS를 루트 파일 시스템으로 마운트했기 때문에 이 작업을 수행할 수 없습니다. (UUID 충돌을 피하기 위해) 다른 컴퓨터에 연결해야 한다고 생각합니다.

관련 정보