sfdisk를 사용하여 더 큰 장치에서 더 작은 장치로 파티션 테이블 복사

sfdisk를 사용하여 더 큰 장치에서 더 작은 장치로 파티션 테이블 복사

파티션 정보와 파티션 데이터를 다시 포맷하고 복사하기 위해 Raspberry Pi 시스템용 Python 스크립트를 테스트하고 있습니다. 첫 번째 장치(일반적으로 USB 스틱)에서 정보를 얻으려면 다음을 사용합니다.

sfdisk -d /dev/sda >sda_data.txt

그런 다음 동일한 테이블을 대상 드라이브에 복사하려면 다음을 사용합니다.

sfdisk /dev/sdb <sda_data.txt

전반적으로 예상대로 작동하지만 더 작은 디스크에서 사용하면 어떻게 되나요? 예를 들어, sda1은 msdos 형식의 부팅 파티션이고 sda2는 드라이브의 나머지 부분을 채우는 extfs 파티션이라고 가정합니다. /dev/sda2의 총 데이터(부팅 명령 및 데이터 제외)가 약 10GB이고 /dev/sda가 64GB라고 가정합니다.

내 데이터는 64GB 장치에서 더 작은 32GB 장치로 파일을 복사할 때 더 작은 장치의 /dev/sdb에 모든 데이터를 더 작은 장치에 저장할 수 있는 충분한 공간이 있을 정도로 작습니다. 따라서 sda가 64GB이고 sdb가 32GB인 경우에도 sda의 모든 데이터를 sdb로 복사할 수 있습니다.

문제는 더 작은 sdb의 파티션에 있습니다.

sda에서 파티션 정보를 읽을 때 여기에는 파티션 크기가 포함되어 있으며 두 번째 파티션 sda2는 새 파티션 sdb2보다 훨씬 큽니다. sdb에서 sda_data.txt의 infodump를 사용할 때 내 경험에 따르면 sfdisk는 sdb에서 더 작은 장치 크기를 허용하고 너무 큰 파티션을 생성하려고 시도하지 않습니다. sdb2에서 자동 이동을 생성합니다. 끝에 있는 파티션은 더 작은 장치.

이것은 내 경험입니다. 이것이 표준적인 행동입니까? sfdisk는 항상 마지막 파티션의 크기를 더 작은 장치로 조정합니까? 즉, sfdisk를 사용하여 더 작은 장치에 더 작은 파티션을 만들 수 있습니까? (이는 sdb가 끝난 후 파티션이 시작되지 않고 해당 장치의 공간을 완전히 초과한다고 가정합니다. 이 논의의 목적에 따라 마지막 파티션을 줄여야 할 수도 있지만 여전히 sdb에 들어갈 수 있다고 가정할 수 있습니다. - 전체 크기는 아닙니다)

답변1

덤프 옵션은 주어진 파티션의 정확한 복사본을 만드는 데 더 적합합니다.

파티션과 장치 크기가 일치하지 않을 때 sfdisk를 사용하는 것이 얼마나 안정적인지 말할 수 없습니다.

그러나 처음부터 또는 덤프를 기반으로 보다 관대한 sfdisk 스크립트를 쉽게 만들 수 있습니다.

예를 들어, sfdisk에서 다음 덤프를 받으면

label: gpt
label-id: 01234567-89AB-CDEF-0123-456789ABCDEF
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 7814037134
sector-size: 512

/dev/sda1 : start=          34, size=       32734, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="Microsoft reserved partition"
/dev/sda2 : start=       32768, size=   629145600, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="something"
/dev/sda3 : start=   629178368, size=  1300070400, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="something else"
/dev/sda4 : start=  1996365824, size=  5817669632, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=01234567-89AB-CDEF-0123-456789ABCDEF, name="root"

장치 경로, 시작 섹터 및 크기 매개변수 중 하나를 제거하여 보다 유연한 파티션을 생성할 수 있습니다.

label: gpt

size=       32734, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, name="Microsoft reserved partition"
size=   629145600, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="something"
size=  1300070400, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, name="something else"
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, name="root"

이렇게 하면 sfdisk가 자동으로 기본 시작 위치를 계산하고 마지막 파티션을 확장하여 남은 공간을 채우고(필요한 크기가 없기 때문에) 파티션에 대한 새 UUID를 생성하는 4개의 파티션이 생성됩니다. 파티션이 이전과 동일한 UUID를 가지도록 하려면 uuid덤프에 매개변수를 유지하기만 하면 됩니다.

관련 부품은 다음에서 제공됩니다.맨페이지:

권장되는 접근 방식은 시작 오프셋을 전혀 지정하지 않고 파티션 크기를 MiB, GiB(또는 그 이상) 단위로 지정하는 것입니다. 이 경우 sfdisk는 모든 파티션을 블록 장치 I/O 제한(또는 I/O 제한이 너무 작아서 디스크 레이아웃을 이식 가능하게 유지할 수 없는 경우 메가바이트 경계)에 맞춰 정렬합니다.

크기의 기본값은 "최대한", 즉 다음 파티션 또는 장치 끝까지를 의미합니다.

일반적으로 sfdisk 스크립트를 직접 작성하는 것이 가능합니다. 부팅 + 루트 설정의 경우(참고: sfdisk를 사용하여 파티션이 어떤 파일 시스템을 갖게 되는지는 중요하지 않습니다) 다음과 같은 간단한 방법을 사용해야 합니다.

label: gpt

size=5GiB, type=linux, name="boot", bootable
type=linux, name="root"

관련 정보