만약 리눅스 커널이 IDE 디스크에 설치된 디스크 매니저를 감지하는 경우
리눅스 커널은 디스크 매니저가 행한 방법과 동일한 방법으로 디스크를
다시 배치하려고 할 것이다.
그러므로 Linux는 DOS와 같이 동일한 디스크 파티션을 인식하게 될 것이다.
명령 라인에서 구조정보가 입력되는한 재배치 작업은 일어나지 않는다.
그러므로 `hd=cyls,heads,secs' 와 같은 명령라인 옵션은 디스크 매니저와의
호환성을 떨어 뜨리게 될 것이다.
재배치 과정은 C <= 1024 이거나 H = 255가 될 때까지 H*C값을 일정하게
유지한체로 헤드의 수를 4, 8, 16, 32, 64, 128, 255 로 차례로 시도함으로서
이루어 진다.
자세한 내용은 아래에 있다. - 아래의 부제목은 해당 부팅 메세지로 나타나는 문자열이다. 파티션의 유형은 항상 16진수로 표시된다.
EZ-Drive 는 프라이머리 파티션의 유형이 55값을 갖으며, 이를 이용하여 인식할 수 있다. 구조정보는 위에서 언급된 것처럼 재배치 된다. 그리고 sector 0에서 부터의 파티션 테이블은 무시된다. 대신에 파티션 테이블은 sector 1에서 부터 읽어 진다. 디스크 블럭 번호는 변경되지 않는다. 그러나 sector 0 번에 쓰는 작업은 sector 1에 쓰도록 변경된다. 이러한 작업은 kernel에서 아래와 같이 변경후 커널을 다시 컴파일 함으로서 이루어진다.
#define FAKE_FDISK_FOR_EZDRIVE 0 in ide.c.
OnTrack DiskManager (첫번째 디스크상에 있는)는 첫번째 프라이머리 파티션의 유형이 54값을 갖으며, 이를 통해 인식 가능하다. 구조정보는 위에서 언급된 방법으로 재배치된다. 그리고 전체 디스크는 63개의 sector만큼 쉬프트 된다. 그러므로 이전의 63번 섹터는 0번 섹터가 된다. 결국 새로운 MBR(파티션 테이블을 포함)은 새로운 섹터 0번으로 부터 읽혀진다. 물론 이러한 쉬프트 작업은 DDO를 위한 공간을 남겨 둘것이다. 이것이 다른 디스크에 대해서는 쉬프트 작업을 하지 않는 이유이다.
OnTrack DiskManager (다른 디스크에 설치된 경우)는 첫번째 프라이머리 파티션의 유형이 51또는 53을 갖기 때문에, 이를 이용하여 식별이 가능하다. 구조정보는 위에서 언급된 것처럼 재 배치 된다.
OnTrack DiskManager의 구버전은 파티션 유형정보를 이용하지 않고, 기호를 이용하여 식별한다. (MBR의 2번째와 3번째 바이트에서 찾은 offset값이 430보다 작은지를 확인하고 이 옵셋에서 발견된 short형의 값이 0x55AA와 같은지 확인한다. 그리고 홀수 바이트가 뒤를 따르는지 확인한다. 구조정보는 위와 동일하게 변환 된다.
마지막으로, 프라이머리 파티션의 시작과 끝 값으로 부터 변환을 유추하려는
시도가 있다.
만약 어떤 파티션이 시작(start)과 끝(end) 섹터 번호로 1과 63을 각각 갖고, 마지막
헤드번호로서 31, 63, 127 또는 254를 갖는 것은, 파티션을 실린더와
경계상에서 끝나도록 하는 관례적인 이유와 IDE 인터페이스가 최대 16개의
헤드를 사용하기 때문이다.
또한 이것은 변환이 이루어졌다고 추측할 수 있고, 구조정보는 32, 64, 128 또는
255개의 헤드로 변환된다.
그렇지만, 현재의 구조가 트랙당 63개의 섹터를 갖고 있고, 적어도 헤드의
수만큼 갖는 경우 재배치 작업은 일어나지 않는다.
(이것은 이미 재배치 작업이 일어났음을 의미하기 때문이다.)