Linux カーネルが IDE ディスク上に何らかのディスクマネージャの存在を
検出した場合、そのディスクマネージャがするのと同じ方法でディスクを
再マップしようとするので、Linux は例えば OnTrack や EZ-Drive を使っている
DOS のように同じディスクパーティションを見ることになります。
しかし、ジオメトリが(訳注: LILOの)コマンドラインから指定された場合は
再マップは行われません
- つまり `hd=cyls,heads,secs'
(訳注: `hdx=cyls,heads,secs' が正しい)
というコマンドラインオプションはディスクマネージャとの互換性を
失わせてしまいます。
再マップは、C <= 1024 になるか H = 255 になるまで、 (H*C が一定であるように) ヘッド数(H)を 4, 8, 16, 32, 64, 128, 255 と増やしていきます。
詳細は以下のようになります - 以下のサブセクションの題名はブートマネージャに対応すると思われる文字列です。 以降、パーティションタイプはすべて 16 進数であらわします。
最初の基本パーティションタイプが 55 であるとき、
EZ-Drive が存在すると判断されます。
ジオメトリは上で説明したように変換され、
セクタ 0 にあるパーティションテーブルは無視されます。
その代わりに、パーティションテーブルはセクタ 1 から読み出されます。
ディスクのブロック番号は変更されませんが、セクタ 0への書き込みは、
セクタ 1 への書き込みに強制されます。
この振る舞いは、ide.c
(訳注: カーネル 2.2.12 では drivers/block/ide.h) の中で
#define FAKE_FDISK_FOR_EZDRIVE 0
としてカーネルを再構築すれば切り替えられます。
(一台目のドライブの)最初の基本パーティションタイプが 54 であると、 OnTrack ディスクマネージャが組み込まれていると判断されます。 ジオメトリはすでに述べた方法で変換され、 ディスク全体が 63 セクタ分ずらされます (つまり、元々のセクタ 63 はセクタ 0 と呼ばれることになります)。 この結果、新しい(パーティションテーブルを含む) MBR は、 新しいセクタ 0 から読み込まれます。 もちろん、このずらしは DDO のための空間を確保するためで、 これが一台目のディスク以外にはずらしが入らない理由です。
(一台目のディスク以外の)基本パーティションがタイプ 51 か 53 のときには、 OnTrack ディスクマネージャが効いていると判断されます。 ジオメトリの変換は上に述べた通りです。
古い OnTrack ディスクマネージャは、 パーティションタイプではなくシグネチャで検出されます。 (検出方法: MBR のバイト 2,3 にある数をオフセットと考え、 このオフセット値が430以下であるか確認します。 次にこのオフセット位置にある short int 値が 0x55AA で、 なおかつ、次の 1 バイトが奇数かどうかを監査します。) 変換方法は、上に述べた通りです。
最後に、基本パーティションの start と end の値から、
変換が行われてることを知る方法があることをご紹介しましょう。
もし、あるパーティションが start と end にそれぞれセクタ番号
1 と 63 を持っていて、さらに end のヘッド番号として 31, 63, 127,
または 254 を持っているとすると、
パーティションの終わりはシリンダ境界におかれる慣習であること、
IDE インターフェースは最大 16 ヘッドであることから、
BIOS による変換がおこなわれていることが分かり、
また、ジオメトリはヘッド数 32, 64, 128, または 255 を使って
再マップされていることが分かります。
しかし、現在のジオメトリがすでにトラックあたり 63 セクタで、
たくさんのヘッドがあるというなら、変換は行いません
(ヘッドがたくさんあるというのは、すでに変換が行われているということですから)。