파티션 오프셋이 63입니까, 아니면 64입니까?

파티션 오프셋이 63입니까, 아니면 64입니까?

OpenBSD 5.5에 전체 SSD를 사용하고 싶지 않습니다. (SSD는 새로운 것이며 Gparted를 사용하여 MSDOS를 통해 사전 포맷되었습니다)

설치 도중과 fdisk 단계에서 OpenBSD를 설치하기 위해 파티션 번호: 0을 선택했습니다(파티션 ID를 a6으로 변경했습니다). 파티션 #: 1 또는 2에 다른 Unix 계열 운영 체제를 설치할 계획입니다.

파티션 오프셋(기본값은 0)을 묻는 메시지가 표시되면 63 대신 64를 입력했습니다(인터넷에서 SSD의 경우 오프셋이 64에서 시작해야 한다고 읽었습니다). 그렇죠?

내 SSD 디스크 구조에 대한 추가 세부 정보는 다음과 같습니다.

디스크 기하학

설치 과정은 문제 없이 순조롭게 진행되었습니다.

컴퓨터를 다시 시작한 후 마지막 몇 줄은 오류 메시지입니다.

root on sd0a swap on sd0b dump on sd0b
panic: root filesystem has size 0
Stopped at Debugger+0x5 : leave
Run at least 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC! IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS TOO.
DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!
ddb{0}>

답변1

오프셋은 512바이트 섹터로 지정됩니다. 63의 대체 오프셋은 더 이상 사용되지 않으므로 무시해야 하는 C/H/S 형상에서 나온 것입니다.

오프셋 64가 63보다 나은 것 같습니다. 분명히 더 균일합니다. 512*64 = 32KiB의 정렬을 제공합니다. 너정말4KiB 정렬을 목표로 삼고 싶습니다. (SSD를 사용하지 않더라도 하드 드라이브는 이제 내부적으로 4KiB 섹터를 기반으로 합니다.)

개인적으로 저는 1MiB에 맞추려고 노력하고 있습니다. 이는 (1024 * 1024) / 512 = 2048 섹터가 됩니다.

다른 모든 현재 운영 체제는 1MiB와 일치하도록 설계되었습니다. (즉, 문제 해결). 이것을 고수하면 이상한 버그를 피할 수 있습니다. 다른 운영 체제(특히 Linux 또는 Windows)를 설치할 때 BSD와 동일한 정렬을 사용하면 파티션 테이블을 더 쉽게 이해할 수 있습니다. 이해하기가 더 쉬우면 오류를 발견하기도 더 쉬울 것입니다. 여기서 생각나는 것은 이전 버전의 데비안에서 겪었던 기존 디스크에 파티션을 만들 때 발생하는 정렬 불량 문제입니다.

최신 플래시 삭제 블록은 32KiB보다 훨씬 큽니다(최소 128KiB/256KiB). 즉, 이는 주로 RAID 목적으로 중요하다고 생각합니다. 이는 대규모 IO에만 중요하고 파일 시스템이 내부적으로 반드시 1MiB로 정렬될 필요는 없기 때문입니다.


기본 오프셋이 0이라고 말하면 걱정됩니다. 섹터 0은 MBR 파티션 테이블(또는 GPT를 사용하는 경우 보호 MBR)이 차지하고 있으므로 파티셔닝에 사용할 수 없습니다. 0이면예전에는사용자(BSD)가 MBR 다음과 같은 다른 위치에서 계산을 시작하고 있으며 이를 보상해야 함을 나타내는 유효한 오프셋입니다.

귀하의 업데이트가 내 우려에 답해주었습니다. 잘못된 오프셋을 0으로 지정하면 "이 파티션 번호가 사용되지 않음"을 의미합니다.

(또한 목적에 맞게 사용할 파티션을 "선택"하는 이유를 설명합니다. Linux fdisk가 표시하는 방식이기 때문에 "만들기"에 대해 설명하겠습니다. 이러한 측면에서 BSD fdisk는 다음과 같은 테이블 형식으로 더 많은 텍스트 보기를 보여줍니다. 여러 기본 파티션).

답변2

예, 이와 같은 문제가 있는 경우 문제를 해결하는 좋은 방법은 cat /dev/zero >/dev/disk(전체 하나)를 실행하여 모든 것을 0으로 만들고 적절하게 정렬된 디스크로 다시 시작하는 것입니다. 이전에 부팅 코드의 기존 부분을 발견하면 오류가 발생하는 경우가 있었습니다.

관련 정보