Linux カーネルが IDE ディスク上にディスクマネージャーを検出
した場合、ディスクをディスクマネージャーが行うのと同じ方法で
変換しようとします。これによって、Linux は DOS が
OnTrack や EZ-Drive を通してみるのと同じようにパーティションを
見ることができます。が、コマンドラインからジオメトリを指定
した場合、変換は行いません。ですから、
hd=cyls,heads,secs
というコマンドラインオプションは、ディスクマネージャーとの
互換性を殺してしまいます。
変換は、(H*Cの値を定数に保ったまま) 4, 8, 16, 32, 64, 128, 255 ヘッドの何れかで行います。これらのうち、C <= 1024 か、 H = 255 の何れかを満たすものが採用されます。
以下の節で、各ディスクマネージャー毎の説明を行います。 以降、パーティションの型はすべて16進数であらわします。
最初のプライマリパーティションの型が55であるとき、EZ-Drive が
存在すると判断されます。ジオメトリは上で説明したように変換
され、セクター0にあるパーティションテーブルは無視されます。
その代わりに、パーティションテーブルはセクター1から読み出
されます。ディスクのブロック番号は変更されませんが、セクター
0への書き込みは、セクター1への書き込みに強制されます。この
振る舞いは、ide.c の中で
#define FAKE_FDISK_FOR_EZDRIVE 0
in ide.c.
としてカーネルを再構築すれば修正できます。
(最初のドライブの)最初のプライマリパーティションの型が 54 で あると、OnTrack ディスクマネージャが組み込まれていると 判断されます。ジオメトリはすでに述べた方法で変換され、 ディスク全体が63セクター分ずらされます(つまり、元々の セクター63 はセクター0と呼ばれることになります)。この結果、 新しい(パーティションテーブルを含む)MBRは、新しいセクター0 から読み込まれます。もちろん、このずらしはDDOのための 空間を確保するためで、これが、最初のディスク以外にはずらしが 入らない理由です。
(最初のディスク以外の)プライマリーパーティションが51か53の ときには、OnTrack ディスクマネージャーが効いていると 判断されます。ジオメトリの変換は上に述べた通りです。
古い OnTrack ディスクマネージャーは、パーティションの型ではなく シグナチャーで検出されます(検出方法：MBR のバイト2,3 にある数 をオフセットと考え、このオフセット値が430以下であるか確認します。 次にこのオフセット位置にある short int 値が 0x55AA で、 なおかつ、次の 1 バイトが奇数かどうかを監査します。)。 変換方法は、上に述べた通りです。
最後に、プライマリパーティションの開始位置と終了位置
から、変換が行われてることを知る方法があることをご紹介しましょう。
もし、あるプライマリーパーティションテーブルのstartおよびend
の値が256未満で、なおかつ開始および終了セクター
番号がそれぞれ 1 および 63 であり、さらに終了ヘッドが
31, 63, 127 といった数だとします。すると、パーティションの終わりは
シリンダ境界におかれる習わしであること、IDE インターフェースは
最大 16 ヘッドであることから、BIOS による変換がおこなわれて
いることが分かり、また、 ジオメトリとしては、32, 64, 128
といったヘッド数が使用されていることが分かります
(多分、これには欠陥があります。genhd.c は、シリンダ
番号の上位2ビットを試験しない方がいいのではないでしょうか)。
しかし、現在のジオメトリがすでにトラックあたり63セクターで、
たくさんのヘッドがあるというなら、変換は行いません
(ヘッドがたくさんあるというのは、
すでに変換が行われているということですから)