8GBの壁を越える

2004/03/21
概要

 最近ではあまり問題なくなったが、一時期IDEハードディスクの8GBの壁の問題はかなり騒がれた。一体これはどういう話だったのだろうか? いきなり結論のような話をして恐縮だが、これは単にハードディスクのアドレス管理に24bitアドレス空間しか使っていなかったからである。2の24乗×512bytes(1セクター)=8GBが他ならぬこの壁の原因であります。これを超える対応をしないと8GB以上のハードディスクを扱えない訳である。

 24bitアドレスはハードディスクのアドレス管理方式として、従来のCHS方式事実上限界であり、これを突破するためにLBA(Logical Block Addressing)方式をサポートする必要がある。多少の補足はいるにしても、8GB超対応=LBA方式対応と考えて頂いて、殆ど問題ありません。

 なあ〜んだ、じゃこれで話は終わりかと言うと、そうはいかない。LBA対応をしていなかったのは一体だれなのかというのが結構問題だからである。

 そしてよく検証してみると、これはまだ現在も問題であることに気づく。実は8GBの壁の問題は実害として、2つの少し毛色の違った表れ方をするからだ。その2つとは以下である。

  1. ハードディスクの先頭から8GB以上の領域にパーティションを作成できない
  2. ハードディスクの先頭から8GB以上の領域にOSカーネルを置けない

 以前一番騒がれたのは1番の方だ。結局8GB超のハードディスクを買ってきてもパーティションが8GB以降に作成できないため、この領域を使うことができず、多くの人が「パソコンが8GB超のハードディスクを認識しないよ」という訴えをしたのはこの件である。

 一方2番の方は比較的最近問題になっていることだ。ハードディスクが非常に大容量になり、一つのハードディスクでマルチOSを楽しむ人が増えたが、その場合に、当然8GB以降の場所にOSカーネルを配置したいと考えるが、その時に、そのような場所に置いたOSカーネルが起動できないという問題である。1番の問題は当然クリアした上で、つまりパーティションは作成でき、フォーマットも完了し、さらにはOSもインストールできた(インストーラの未対応でここで躓く場合もある)のに、再起動してみるとブートしないという新たな問題として、最近浮上してきていることである。

 さて、これらの問題はそれぞれ、一体だれが絡んでいるのだろうか。

 


登場人物

 この問題の登場人物は以下の面々になる。

  1. BIOS
  2. IDEディスクコントローラ
  3. パーティション作成ツール
  4. ファイルシステム
  5. OSカーネル
  6. ブートローダ
  7. アプリケーション
各問題への登場人物の関わり度 ◎強 ○弱 −なし
  パーティション作成不可 OSカーネル配置不可
BIOS
IDEディスクコントローラ
パーティション作成ツール
ファイルシステム
OSカーネル
ブートローダ
アプリケーション

 関わり度の強弱の違いは重要度を表している訳ではない。いずれが欠けても問題は起こるので、等しく重要なのだが、実際LBA対応が早かったため、それがボトルネックになって問題を引き起こした場合が少なかったものもある。このようなものは問題の原因になった関わり度的には弱いと言えるという話である。


 BIOSは今回の問題でかなりのキーマンになる。BIOSの場合、INT13HというディスクI/Oルーチンがあり、従来はこれがCHS方式しか対応しておらず、LBA方式対応の拡張INT13Hの採用という形で対応することになる。

[BIOSコールのLBA対応]

BIOSコール LBA対応
INT13H ×
拡張INT13H


 IDEディスクコントローラの場合、ある意味対応していて当然という意味合いが強い項目だ。IDEディスクコントローラはマザーボード側のものと、ハードディスク側のものがあるが、実際8GB超のハードディスクそれ自身のコントローラがよもやLBA対応していないなどということは考えられないし、マザーボード側のコントローラもかなり早くから対応していた。実際古いマザーボードに接続しようとした場合、当然問題が起こりうる訳だが、その場合はまずBIOSの対応もできていないはずで、IDEディスクコントローラだけの問題として表れる場面は少ないと考えられる。

[IDEディスクコントローラのLBA対応]

コントローラ LBA対応
IDE ×
Enhanced IDE


 パーティションの作成問題に、パーティション作成ツールが深く関わるのは当然である。ただしパーティション作成ツールはディスクアクセスにBIOSを利用するものが非常に多く、対応といってもBIOSの拡張INT13Hを利用できるという形の対応になる。従って共にBIOSが対応していないと意味のない場合が殆どだ。

 パーティション作成ツールとしてはDOSやWindows9xのFDISKや、LinuxのCFDISK、WindowsNTのディスクアドミニストレータなどがあるが、多くはBIOSを利用します。当然BIOSを利用しないものは自身さえ対応していれば、それで済みます。

[パーティション作成ツールのLBA対応]

パーティション作成ツール LBA対応(対応バージョン) BIOS利用
MS-DOS6.xのFDISK ×
Windows9xのFDISK ○(Windows95 OSR2)
WindowsNTのディスクアドミニストレータ ○(4.0) ×
Windows2000のディスク管理 ×
LinuxのFDISK ○(不明)
LinuxのCFDISK ○(不明)
FIPS ○(1.5c)
Partition Rasizer ○(1.3.0)
GNU Parted
PartitionMagic ○(4.0)
Partition-IT ×
PARTITION COMMANDER
Ranish Partition Manager ○(2.3.8β)

 WindowsNTやWindows2000の場合、インストール時のパーティション作成フェーズがあるが、これに関しては上記のディスクアドミニストレータやディスク管理の場合と同じ対応状況になる。


 パーティション作成ツールと表裏一体の関係にあるものとしてフォーマットプログラムがあり、フォーマットプログラムは当然それが作り出すファイルシステムというものがある。そのファイルシステムはやはりファイルの位置、つまりアドレスを管理する訳で、その管理方式にLBA対応という問題が当然起こる訳だが、普通パーティション作成ツールとフォーマットプログラムはOSに付属するものとしてセットで提供されるはずで、一方が対応して他方が対応していないということは考えられない。

[ファイルシステムのLBA対応]

ファイルシステム LBA対応 利用可能なOS
FAT16 × 全てのMicrosoftのOS
FAT32 × Windows95 OSR2以降
FAT16X Windows95 OSR2以降
FAT32X Windows95 OSR2以降
NTFS WindowsNT以降
EXT2 Linux

 パーティション作成ツールの場合や、ファイルシステムにおける利用可能なOSを見ても明白なように、Windows95 OSR2というのがLBA対応の一つの分水嶺になっていることが見て取れると思う。

 FAT32FAT32Xに関しては共にWindows95 OSR2以降からの対応でありながら、前者はLBA未対応となっているが、これはFDISKコマンドが作成しようとするパーティションのサイズと位置によって自動的に作り分けるので、利用者が気にする区分ではない。

 OSカーネルは大抵IDEディスクコントローラと直接やりとりするドライバを持っているので、BIOSに引きずられるということはない。IDEコントローラさえ対応していれば、自身の対応だけで済む。しかしOSに付属するパーティション作成ツールでパーティションを作成しないことには結局OSカーネルはインストールできないので、普通はOSカーネルの未対応で躓く前に、パーティション作成ツールで躓く。

 また、OSカーネルは自身より新しいバージョンのファイルシステムには対応していなので、LBA対応のパーティション作成ツールで作ったLBA対応のファイルシステム上に、未対応のOSカーネルが載るということはないはずである。従ってOSカーネルが対応していないので困った、という場面に遭遇すること、つまりOSカーネルの未対応が明るみに出ることはまずない。

 結局OSカーネルの対応はその付属のパーティション作成ツールと全く同じだが、一応以下に記載しておく。

[OSカーネルのLBA対応]

OSカーネル LBA対応(対応バージョン)
MS-DOS6.x ×
Windows9x ○(Windows95 OSR2)
WindowsNT
Windows2000
Linux ○(2.0.34)*
FreeBSD ○(2.2.8)

 *Linuxの場合、不具合対策をした2.0.34が完全なものだが、そもそもLinuxカーネルは当初からLinearアドレスを内部では使用していたので、IDEのLBA対応もすこぶる早く、既にVersion1.2.0では対応済みである。正確に対応したバージョンが分からないが、相当古くからなので、まず問題はないはずである。 

 さて、ブートローダだが、こちらはOSカーネルの配置場所の問題となるので、一応それ以外の問題は全てクリアしていることが前提になる。そもそもパーティションが作れなかったり、そこにOSカーネルをインストールできないのではOSカーネル起動の問題など起こりようがないからである。

 そして現実にブートローダの対応が最も遅れている。他のものは殆どが1998年中にはほぼ対応を終えたのに対し、以下の表は2001年4月の時点のもので、やっと多くのブートローダが対応を済ませたが、実際対応したは殆どが2000年に入ってからである。

[ブートローダのLBA対応]
ブートローダ LBA対応(対応バージョン)
IBMオリジナルIPL ○(Win95 OSR2)*1
NTLDR ○(Win2000)
LILO ○(21-3)
MBM ○(V0.31)
Extended-IPL ○(V5.00)
GNU GRUB ○(?)
XOSL ○(?)
SBM ○(?)
GAG ○(V4)
SyMon ○(R2)
BootIt ○(2001)
OS/2ブートマネージャ ×
BootMagic ○(2.0)
SYSTEM COMMNADER ○(4 SP3)
SYSTEM COMMNADER Personal
BootWare
SystemSelector
Select-IT ×
RPM ○(V2.3.8β)
Booteasy ×(後継のboot0は対応)
OS-BS ×
Bootactv ×

*1 FAT16X、FAT32Xパーティションに対してのみLBAモードを使う

 どうしてこのようにブートローダの対応は遅れたのだろうか。その答えは実は明白である。

 OSにとって昨今8GBのハードディスクを扱えるように対応することは極めて重要である。しかしOSカーネル自身が8GB以降に位置しなければならない必然性はない。OSカーネルが8GB以降に位置できるよう対応するということは他のOSとの共存に便宜を図ることになる。

 メジャーなOSにとって、わざわざ苦労して他のOSに場所を明渡すような対応する必要があるだろうか。少なくともMicrosoftのOSがそんなことをする訳がない。NTLDRの対応も他社のOSのためではなく、他のWindowsファミリーのOSとの共存を意識した対応だと考えられる。

 従ってマイナーなOSの方が対応は早いようだ。もっともサードパーティのブートローダの場合、もっと早い対応でもよかったと思うのだが、現実にはそれ程迅速に対応されなかった。

 8GB超とはいっても、10GBや13GB程度のハードディスクの場合、8GB以降にOSの先頭を置きたいという場面は少ないと考えられる。20GB程度のハードディスクになって、はじめて8GB以前にOSを入れなければならないという制限が現実的に障害になってきたと考えられる。20GBのIDEハードディスクが市場を席巻したのは2000年に入ってからである。結局あまり要求がなかったから、対応が遅れたという事情もあるだろう。

 

 最後のアプリケーションだが、普通ディスクアクセスはOSカーネルが責任を持つ(アプリケーションはOSが提供するAPIを利用してディスクアクセスを行う)ので、アプリケーションの対応が問題になる場合は殆どない。極一部のディスクに直接アクセスするアプリケーションの場合、自身の対応が問題になるが、普通はあまり気にする必要はない。少なくともパーティションの作成やブートとは関係はない。

 

 さて、結論めいた話が先行してしまったが、この問題を正しく理解するにはまず問題となったハードディスクを扱うアドレス空間、それと大きく関わるアドレス方式について理解する必要がある。少し歴史について考察してみよう。

 


CHS方式

 以前はBIOSもディスクコントローラもすべて以下に示す C/H/S (シリンダー数、ヘッド数、セクター数) 3つ(3次元)のパラメータを用いたCHS方式のアクセスをしていた。これらの3つのパラメータ値はそれぞれ以下のような意味を持つ。
 

  1. ヘッド
    通常ディスク1面を1つの磁気ヘッドが担当するので、磁気ヘッドの番号を指定するだけで、どのディスクのどの面かは指定できる。そのままディスク面を指して、サイドと呼ぶ場合もある。
     
  2. シリンダー
     ディスク記録面(サイド、ヘッド)には多数のトラックと呼ばれる同心円状の円周で分割されており、ハードディスクのように複数のディスク面がある場合、各ヘッドの同一トラック(たとえば最外周とか)を繋ぐと、ちょうど円筒(シリンダー)のようになるのでトラックの指定のことをシリンダーと呼ぶ。たとえディスク面が1面でもそう呼ぶ。
     
  3. セクター
    各トラックは更にセクターと呼ばれるもので分割されており、これがディスク上のデータの最小単位となる。PC/AT互換機の場合、その1セクターは512bytesである。UNIX-OSなどではブロックと呼ぶ場合もある。
     
 元々のマザーボードのBIOSの仕様ではシリンダーに10bit、ヘッドに8bit、セクターに6bitの計24bitが与えられていた。よって、理論的には1024(10bit)X256(8bit)X63(6bit、セクターは6bitとはいっても1から数える関係で64ではなく63しか使えない)X512bytes=8,455,716,864bytes(約8GBytes)となる。

 24bitの制限とは具体的にはこのことになる。ではまずどうやって8GBの壁を突破したのかの話に入る前に、せっかくなので、8GBの壁に達するまでの以前の壁についても見てみよう。その方が8GBの壁についてもより理解できるし、今後の壁の可能性についても理解しやすいかもしれない。

 


504MBの壁

 もうあまり記憶ない人もいるかもしれないが、IDEには504MBの壁があった。E-IDE規格の登場でこの制限が撤廃されたが、この壁はいったいどうして起きたのだろうか?

 元々のIDE規格ではシリンダーに16bit、ヘッドに4bit、セクターに8bitと、計28bitのアドレッシングだった。よって規格そのものの上限は65,536(16bit)X16(4bit)X255(8bit)X512bytes=136,902,082,560(約128G)Bytesもあった。しかしそれぞれの割り当てがBIOSと異なっていたため、双方で使えるビットが制限される。以下に表にして見た。

 
  シリンダー

ヘッド

セクター サイズ
BIOS 1023(10bit) 256(8bit) 63(6bit) 8GB
IDE 65536(16bit) 16(4bit) 255(8bit) 128GB
現実 1023(10bit) 16(4bit) 63(6bit) 504MB

 結局それぞれの小さい方が採用されてしまうために、IDEでは504MBに制限されてしまった訳だ。そこでこれを突破するためにジオメトリを変換する方法が考案された。(もっともこの壁以前にもジオメトリ変換は行われていた。これについては『504MBの壁以前のジオメトリ変換』を参照してほしい)

 


ジオメトリ変換『LARGE』

 BIOSとIDEコントローラとの間で、ジオメトリの変換を行うのだが、その方法の一つにLARGEがある。

 これはBIOSとIDEコントローラとのやり取りではIDEの仕様に従って16bitおよび4bitで表現されるシリンダー番号、ヘッド番号を使い、一方BIOSとOSとのやり取りではもともとのBIOS仕様に従った10bitおよび8bitで表現されるシリンダー番号、ヘッド番号を使う、という方法である (セクター番号はBIOS仕様に合わせて63を使う)。

 具体的にはIDEコントローラから来るジオメトリー情報をもとに、シリンダ数を 2 で割ってヘッド数に 2 をかける手順を繰り返し、シリンダ数が 1023以下になるか、あるいはヘッド数が128を超えるまで続けるか、あるいはヘッド数を 255 として「シリンダ数×ヘッド数」で求めた全セクター数をこの 255で割ってシリンダ数を求めます。そしてこの手順で求めたシリンダ数、ヘッド数によるジオメトリをOSとのやり取りでは使う訳だ。

 こうすればBIOSが持つ24bitアドレッシングの上限、つまり8GBまではいけることになる。

 


LBA方式を利用したジオメトリ変換

 LARGEのようなジオメトリ変換方法ではないのだが、CHS方式とは別のLBA方式というハードディスクアドレス管理方式を用いることで、ジオメトリの変換を実現した。E-IDE規格の登場でIDEコントローラ側がLBA方式に対応したのである。

 LBA方式とはそもそもシリンダー、ヘッド、セクターといった3次元アドレスなど一切使わないで、1直線(リニア)に先頭からセクターに連番を振ってしまえばいいのではないかと考えである。(そのためLBAをLinear Block Addressingの略だとの誤認識があったが、これはLogical Block Addressingが正しいようである)

 LBA方式自身は勿論「ジオメトリ変換方法」ではなく、CHS方式に対応したそれとは全く別のハードディスクドライブアクセス方式なのだが、システム全体から見れば、CHSでコールされるOSとLBAでアクセスするハードディスクとの間でBIOSが行うジオメトリ変換作業という位置付けになる。ハードディスクアクセス方式としては。3つのパラメータを用いるCHS方式とは異なり、パラメータ値はただ1つになる。

 さらにこれはあくまでBIOSとIDEコントローラ間の話なので、BIOSとOS間(INT13Hコール)では依然CHS方式に支配されており、結局BIOSが持つ24bitの制限を持つことになる訳である。

 これが今回の主題である「8GBの壁」という訳である。

 さて、ここまでをちょっと整理しよう。少なくともIDEコントローラに関してはもともと28bit、128GBに対応していた上、E-IDEではLBA方式にも対応して、8GBの壁には何ら関わっていないことはご理解頂けていると思う。この時点での足かせはBIOSに他ならない。

 


SCSIの場合

 8GBの壁はIDEに限った話だが、SCSIはどうしてこの壁が無かったのだろうか。今までの説明を見ると確かに504MBの壁はIDEならではの壁だったことが理解できるが、8GBの壁が無かった理由がちょっと思いつかない。勿論ジオメトリの基本的な考えた方は共通だが、今まで見てきたように壁の原因にはマザーボードのBIOSが深く絡んでいるが、SCSIにはSCSI BIOSがあり、多くの場面ではSCSI BIOSがマザーボードBIOSの代わりをするため、SCSI規格の拡張だけで対応していける。

 大容量化をIDEより先行して進めていたSCSIでは『504MBの壁以前のジオメトリ変換』でも言及しているように、早い時期からCHSの3次元アドレスが破綻していた。LBA方式はこのころSCSI規格で考案されたものである。幸いPC/AT互換機のMBRのパーティションテーブルには各パーティションの情報として割り当てられている16bytesの内、8bytesしか事実上まだ利用されていなかった(利用していたけど必須の情報ではなかった)ので、従来のアドレス領域をそのままにしても、残りの8bytesで先頭位置と長さ(これで終端が分かる)に4bytes(32bit)ずつLBA格納用に割り当てることができた。よって理論的には2の32乗×512bytes=2TB(2テラバイト、2048GB)まで対応できる。

 つまりSCSIでは実際8GBなどという大容量のハードディスクが市場に登場する前に対応を済ませてしまっていたということになる。しかし若干ではあるが、やはり対応の遅れたアダプタなどもあり、問題となった事例も皆無ではない。

 


8GBの壁の突破

 さて多くのOSカーネル、ディスクコントローラが対応を済ませた今、やはりBIOSの対応が最終的に8GBの壁を突破するには必須になってきた。外堀は完全に埋められたという感じだ。

 やっとBIOSもINT13Hコールに拡張オプションを用意するという形で対応した。勿論この拡張オプションはLBA方式に準拠したものである。現在発売されているマザーボードはほぼ対応していると思うが、昔のマザーボードの場合、対応しているものは少ないのでBIOSのアップグレードなど行う必要がある。BIOSのアップグレードでは対応できないか、BIOSのアップグレードがされない場合はマザーボードを交換する他ないだろう。

 ただし拡張したと言っても以前のものとの互換性のためオプションとしての拡張なので、BIOSコールを呼ぶ側でそのオプション付きで呼ぶという手続きを踏む必要があり、何でも自動的に拡張される訳ではないことは気をつける必要がある。このあたりが、BIOSのコールを使うパーティション作成ツールなども合わせて対応する(拡張INT13Hを使う)必要がある所以である。

 


アドレッシング方式とサイズの関係

 私は今まで、8GBの壁突破にはアドレッシング方式としてCHS方式からLBA方式への移行が不可欠なのだと説明してきた。これは事実なのだが、CHS方式が大容量にとって致命的な方式であったこということではない。

 8GBという数字は最初の方でも述べた通り、24bitという数値に由来している。ところがCHS方式そのものは何ら規格的に24bitと結びついている訳ではない。別にシリンダーに何bit使おうが、ヘッドに何bit使おうが構わない訳である。現にIDEではもともとCHS方式でありながら28bitアドレスを持っていた。だから方式そのものは決して特定のbit数やサイズ上限と関係している訳ではない。

 ただCHS方式の場合、bitを拡張する時にどの値に割り振るかによっては現実のハードディスクの拡張と整合しない場合もある。前述しているように無駄なbitがどうしても出てくる。無駄なbitも出ない、柔軟性のあるLBA方式に比べて、拡張に向いていない。だからbit拡張時にLBA方式に移行するのは自然の流れになる。

 またこれが一番重要なのだが、ハードディスクのMBRのパーティションテーブルにはCHS方式用に24bit分、LBA方式用に32bit分の領域がある。互換性を保つために双方あるのだが、その趣旨からすると勝手にLBA方式用の領域をCHS用に使う訳にもいかない。パーティションテーブルの情報がハードディスクの位置情報としては基礎になるので、勿論ここを使わない訳にもいかない。結局CHS方式を使う限り、24bit以上は使えないということになる。

 このため事実上、24bit突破、つまり8GB突破にはLBA方式対応は不可欠とさせる訳である。決して方式そのものにサイズ的に致命的な欠陥があった訳ではないことは記憶しておいてほしい。

 


1024シリンダーという表現

 ところで、この8GBの壁についてよく1024シリンダー上限というような表現を聞いたことのある人が多いと思う。確かにこの壁はCHS、24bit全体の壁というよりはむしろCylinder、10bitの壁であり、そういう意味では必ずしもサイズ的に8GBが上限ではない。ヘッドやセクターがビットをフルに使っていない場合、8GBよりも早く上限が来てしまう。現実に昔はそのような事例も沢山あった。

 しかし前述しているように、CHSのジオメトリはかなり以前から破綻しており、シリンダー数いくつなどという表現は現実的意味を失っている。従って現在では1024シリンダー上限という表現は現実的にナンセンスな表現だと私は思っている。

 


CHSの呪縛

 ところで、こうしてLBA方式になっても依然CHSの呪縛から完全に解き放たれた訳ではない。ハードディスクに関しては、BIOS、IDEコントローラ、OSと登場人物が多いため、完全に同期をとって進化することは難しい。いずれかが古い方式、つまりCHS方式しかもっていないことを考慮して、下位互換性を持たなければならない。具体的にはそれぞれのインターフェースにおいて、その互換性をとることになる。コンピュータプログラムを開発したことのない人には分かりにくい概念で、実感はできないと思うが、異なったシステム間のインターフェースの変更は非常に厄介であり、つねにトラブルの温床となってきた。

 インターフェースの仕様で重要なのはパラメータのとそのだが、型の場合はキャストという方式で何とかなってしまう場合が多い。しかし、パラメータの数はどうにもならない。これが変わるとインターフェースの互換は取りようがないのだ。そのため、それぞれのインターフェースでは依然3つのパラメータでやりとりを行う場面が多い。つまりパラメータの数はCHSと同じにする訳である。LBAはひとつの値で済む訳だが、これを何らかのルールに従って、3分割してインターフェースでは使うということである。

 これが現在でもシリンダーとか、トラックというCHSを基礎とした用語がハードディスクの世界に残り続ける理由になっている。単に用語として残っているだけなら良かったのだが、この3分割のルールがきちんと決まっていないため、またまた混乱の元になっていることは「LBA時代のCHS」で述べているが、後述するように、早くも32GBで次の壁に突き当たるようなトラブルの原因ともなっている。

 


次なる壁(1)-32GB

 先に触れたようにやっと8GBの壁を突破したと思ったら、早くも32GBで次の壁に突き当たった。これについては多くのサイトにおいて、Award BIOSのバグであると報告されているが、多くのメーカー製PCでも問題が起きており、どうもAward BIOSだけの問題とは私には思えないのだが、確かな証拠はない。そのAward BIOSのバグとは次のようなものだ。

 前述したように依然インターフェースでは3つのパラメータを使っているが、その分割方式として、IDEの下限とBIOSの下限双方に対応するため、ヘッドを16、セクターを63と固定して、LBA値をこれらで割った商をシリンダーとするというものが一般的だ。そして3つのパラメータの型は、数値なのでintegerという整数値を扱う型を用いる。このintegerには大別して2種類ある。ひとつは16bitOSの時代から使っており文字(charactor)型と互換性のあるshort integerと、もうひとつは32bitOSでは数値を扱う最も一般的な型であるlong integerがある。これをAward BIOSは本来long integerを使うべきだったのに誤ってshort integerを使ってしまったというのである。

 short integerは16bitなので、65535までの数値しか格納できない。勿論ヘッドとセクターには十分な領域であるがシリンダーがこの上限に突き当たると全体で32GBまでしか格納できないことになってしまう訳である。

 これがいくつかのサイトで説明されている32GBの壁の真相である。Award BIOS以外にも問題があったとしても、恐らく原因は同じようなものであろう。

 ところで問題の焦点を変数のに求めているが、私は確かに型も問題だったのかもしれないが、3分割の方式も何とかならなかったのかという疑問もある。つまりヘッド16とセクター63であるが、BIOS下限またはIDE下限のいずれかを用いれば、問題はもう少し先まで起きなかったはずである。

 ただいずれにしても問題は、8GBの壁の時ほど深刻ではなかった。CHSというそれまでのやり方に限界が訪れ、LBAという全く違うものを考案する以外に解決の方法がなかった8GBの壁に比べれば非常に単純なものである。解決もBIOSのアップグレードだけで良かった。そのため8GBの壁ほど尾をひいてはいない。少なくとも私は直接32GBの壁に遭遇したことはない。

 しかしトラブルそのものは8GBの壁の時以上に致命的だったようだ。8GBの壁の時は文字通り8GBが壁となって、8GBまでしか使えないという事例が圧倒的だった。しかし32GBの壁の場合、BIOSがハングしてPCの起動もできなかったというトラブル事例が多く報告されている。また使える場合もハードディスク容量から32GBを引いた量、例えば40GBのハードディスクだったら、8GBまでしか使えなかったという事例も多い。40GBという容量は一時期は一般的な容量だったので、多くの人が使ったはずである。8GBまでしか使えないので、最初は8GBの壁の再来と思った人が多かったようだ。

 


次なる壁(2)-128GB

 前述の32GBの壁と違って、多くの人が必ずやってくると予測していた次の壁が128GBの壁である。これはIDEの規格の上限28bit(128GB)だからである。IDEの規格の変更をしない限り、必ず訪れるのは周知のことであった。勿論ベンダーも早速規格変更に乗り出した。Maxtorが提唱したBig Drive規格である。28bitから一挙に48bitに拡張したのだ。

 対応BIOSとOSでいいそうだ。IDEコントローラも対応が必要なはずだが、こちらはかなり前から28bit以上に対応できるように作ってあったのか分からないが、特に変更は必要ないらしい。ただし正式対応は特定のチップセットに限られるみたいだ。

 尚、Windows系で128GBを超えるハードディスクを利用するのに気をつける点については以下が詳しいのでご参照願いたい。

 


永遠のいたちごっこ

 そして次なる壁は32bit、2T(テラ)Bである。PC/AT互換機の問題なので、SCSIでも同じ運命だ。さらにはCPUやOSもまだ32bitが主流なので、これはかなり大きな問題となることは必至だ。2TBというと以前はすごい数字だと思っていたが、もうそこまで来ている。

 今MBRのパーティションテーブルは位置情報が冗長なのでまだ拡張の余地がある。CHSに使っている24bit分をつぶせるから、56bitまでいけるということだね。勿論以前のCHS方式を使っているものとの互換性は失うが、恐らくCPUとOSの32bit問題の方が障壁になるだろう。

 結局壁は永遠に続く訳だね。

 


目次へ
inserted by FC2 system