파티션 테이블의 단위가 섹터인 것으로 알고 있습니다. 그러나 그 크기는 물리적 섹터 크기입니까, 아니면 논리적 섹터 크기입니까?
파티션 테이블의 숫자는 항상 섹터 수로 기록되므로 논리적 섹터 크기가 물리적 섹터 크기와 다를 때 Linux 커널 및 파티셔닝 도구는 파티션 크기를 어떻게 처리합니까?
답변1
보시다시피 예를 들면위키피디아, GPT의 항목은 LBA(논리 블록 주소)입니다. 이는 논리 섹터 크기를 기반으로 하는 주소입니다.
하드 드라이브가 다른(더 큰) 물리적 섹터 크기를 갖기 시작했을 때 공급업체는 기존 시스템이 새 하드 드라이브를 사용할 수 있도록 기존 물리적 섹터 크기를 논리적 섹터 크기로 유지했습니다. 이는 하드 드라이브 펌웨어에 논리적 섹터 읽기 및 쓰기를 처리할 수 있는 코드가 포함되어 있음을 의미합니다. 읽기의 경우 올바른(더 큰) 물리적 섹터를 읽고 그 중 일부만 반환합니다. 쓰기를 위해 먼저 (더 큰) 물리적 섹터를 읽은 다음 일부를 수정한 다음 다시 이동합니다.
이는 물리적 섹터의 시작에 해당하고 길이가 물리적 섹터의 배수인 LBA에서 읽기 및 쓰기가 발생하지 않는 한 비효율적입니다.
따라서 커널이 대규모 물리적 섹터를 처리하는 방식은 그러한 읽기 및 쓰기만 사용하려고 시도하는 것입니다. 이를 위해서는 파티션이 다음과 같아야 합니다.조정정확합니다(물리적 섹터 경계에서). 일반적으로 파티셔너는 이것이 사실인지 확인하고 잘못된 방식으로 사용하려고 하면 경고를 인쇄합니다.
커널은 이 작업을 수행할 필요가 없습니다. 그렇지 않은 경우에도 작동하지만 효율성은 떨어집니다.
편집하다
사용자 영역 응용 프로그램이 /sys를 통해 논리 섹터 크기를 읽고 파티션 테이블을 읽은 다음 이를 곱하여 사용자에게 파티션 크기를 알려줄 수 있습니까?
예, 이것이 사용자 영역 응용 프로그램이 수행하는 작업입니다 (물리적 및 논리적 섹터 크기가 가 아닌 에 fdisk있다고 생각하지만 이를 찾아봐야 할 것입니다)./proc/sys
커널이 파일 시스템을 운영할 때 기본 저장소의 크기를 알 필요는 없고, 파일 시스템의 메타데이터를 읽어서 파일 시스템 구조의 크기만 알면 되는 거겠죠?
약간 어렵습니다. 기본 커널 단위는 "페이지"(MMU 단위)인 반면 특정 파일 시스템의 기본 단위는 "블록"(때로는 여러 페이지)입니다. 커널은 LBA를 계산하는 데 필요하므로 이것이 기본 스토리지의 논리적 블록 크기와 어떻게 관련되는지 알아야 합니다.
하지만 사용자 모드가 /dev/sda2와 같은 원시 파티션 장치에 액세스할 때 커널은 파티션의 시작 위치와 크기를 알아야 합니다. 그렇죠?
예. 이것이 바로 다음 과 같은 /dev/sda2항목을 생성하기 전에 파티션 테이블을 읽는 이유입니다.
커널이 이 작업을 할 때 파티션 테이블에 기록된 수치 단위가 물리 섹터 크기가 아닌 논리 섹터 크기라는 것을 알아야겠죠?
예.