如果 Linux 侦测到 IDE 磁盘上有某些磁盘管理程序存在, 它将会试著使用与该磁盘管理程序相同的方式来重新对应磁盘, 所以 Linux 看到与, 例如 DOS 配合 OnTrack 或是 EZ-Drive 相同的磁盘分割
然而, 当你在指令列上指定 geometry 时, 就不会做任何的重新对应 - 所以一行 `hd=cyls,heads,secs' 指令列选项可能取消掉与磁盘管理程序的兼容
此重新对应的方式是尝试 4,8,16,32,64,128,255 磁头数(H*C 保持不变)直到 C <= 1024 或是 H = 255
细节如下 - 小节的抬头是出现在相对应之启动信息里的字串 在此以及在这份文件任何其它地方中分割的型态都以十六进位数字表示
侦测到 EZ-Drive , 因为第一个主要分割区型态为 55 如上述重新对应 geometry, 且忽略从第 0 磁区读入的分割表 - 以第 1 磁区的分割表取代 磁盘的区块号码(block numbers) 没有改变, 但对磁区 0 的写入会转向磁区 1 此动作可以藉由修改在 ide.c 中的
#define FAKE_FDISK_FOR_EZDRIVE 0
侦测到 OnTrack DiskManager(在第一个磁盘上), 因为第一个主要分割区型态为 54 如上述重新对应 geometry 而且整个磁盘平移 63 个磁区 (所以旧的磁区 63 变成磁区 0)然后从新的第 0 磁区读入新的 MBR (与分割表) 此平移当然是为 DDO 留空间 - 这也就是为什么其它磁盘不必平移
侦测到 OnTrack DiskManager(在其它磁盘上), 因为第一个主要分割区型态为 51 或 53 如上述重新对应 geometry
侦测到某旧版的 OnTrack DiskManager, 并非藉由分割区型态, 而是签名(signature) (测试在 MBR 里第 2,3 位元组的偏移值是否不大于 430, 而且在此偏移位址找到的 short 等于 0x55AA, 后面并跟著一个奇数的位元组) 再一次如上述重新对应 geometry
最后, 核心会尝试从主分割区的 start 以及 end 值推断转换方式: 若某些分割区的 start 以及 end 磁簇小于 256, 而且 start 以及 end 磁区号码分别为 1 和 63 , 而且 end 磁头为 31, 63, 或 127, 那么, 因为依惯例分割区会在磁簇边界结束, 而且更因为 IDE 界面最多使用 16 个磁头, 故推测有开启 BIOS 转换, 分别使用 32, 64 或 128 磁头数重新对应 geometry
(也许这里有点瑕疵, genhd.c 不应该测试磁簇号码前两个位元吗?)无论如何, 当目前的 geometry 已经为每磁轨 63 个磁区且至少这么多磁头时, 不会做重新对应 (因为这可能意谓著重对应已完成)