容量の壁とは? わかりやすく解説

容量の壁

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2025/03/30 04:31 UTC 版)

容量の壁(ようりょうのかべ)とは、主にハードディスクドライブ半導体メモリーなど、コンピュータ記憶装置に関する、規格性能上の限界を指した概念である。

これは突破する新たな技術の登場を待つ意味でもと呼ばれるが、壁に突き当たるケースとしては規格策定時点で想定していなかった大容量になるまで規格が現役として存続している、大容量化が想定以上のスピードで進んで壁を突破する新たな技術の開発が追いつかない、規格上は想定内だが複合的な要因が重なるなどがあげられる。

ディスク

補助記憶装置(ハードディスクやSSDなど)に関与する容量の壁の原因には、ATAなどインターフェイスや、OSのファイルシステムなど、様々なものがある[1]

場合によっては、BIOSファームウェアデバイスドライバの制限またはバグにより容量の壁が生じ、最新版にアップデートすると制限を解消できる。制限容量以上のHDDを接続したことで誤動作する場合は、HDD側の設定により認識容量(見かけの容量)を減らすことで、制限容量までは扱えるようになる。

ハードディスクの容量表記にはSI接頭語2進接頭辞の問題(換算値の違い、誤差)があり、壁問題としては厳密な容量の表記がされない慣習である。

32MiBの壁

PC/AT互換機用MS-DOSのバージョン3では、FAT16のサポートが追加されたにも関わらず、セクター数を16ビットで管理していたため、32MiBを超えるパーティションを扱えない。これはFAT12の制限と同じである。また、ファイルのサイズについても、ファイルテーブル(ディレクトリエントリ)ではMS-DOSの登場当初から32bitのデータが記録できるように設計されていた(すなわち4GiBまで対応可能)が、単一のファイルが複数のパーティションにまたがって記録されることは想定されていなかったため、必然的に、ファイルサイズの上限は32MiBとなる。

なお、NEC PC-9800シリーズ富士通 FM TOWNS用のMS-DOSバージョン3.xでは、OSから見えるセクタサイズは1KiBまたは2KiBとなっており、最大128MiBまでのパーティションを管理することができた。

504MiB (約528MB) の壁

IDE HDDのパラメータの制約
HDD側 BIOS側 小さい方
シリンダ番号 (C) 0 - 65535 0 - 1023 0 - 1023
ヘッド番号 (H) 0 - 15 0 - 254 0 - 15
セクタ番号 (S) 1 - 255 1 - 63 1 - 63
最大容量 128GB 7.8GB 504MB

ATA規格では、1993年ごろ問題になったのが約528MB(504MiB、512×1024×16×63 = 528,482,304バイト)の壁だった。これはIDE HDDとPC/AT互換機のBIOS (en:INT 13h) の組み合わせにより生じる問題である。 HDDにアクセスする最小単位であるセクタを指定する (アドレッシング) には、シリンダ、ヘッダ、セクタをそれぞれ指定する必要があった。この各要素の最大値がHDDとBIOSで異なっており、これが原因で、それぞれの数値をより小さい一方にあわせる必要があり、HDDはC=65,536、H=16、S=255に対し、BIOSはC=1,024、H=255、S=63であり、実際に扱えたのはC=1,024、H=16、S=63 (1,032,192セクタ、LBAでは20bit相当) で、それが壁となった。HDD側及びBIOS側だけを見ればもっと大きな容量のアドレッシングが可能で、理論上の最大値はHDD側が128GiB、BIOS側が7.875GiB (約8.4GB) だった。

2GiB/4GiBの壁

ボリュームサイズの制限と、ファイルサイズの制限がある。

ボリュームサイズの制限

ファイルシステムFAT16を用いた場合のボリュームサイズの最大値は、2GiB(NT系では4GiB)までとなる。最大クラスター(アロケーションユニット)総数は16ビットで、その内最大65,524までが領域として使用でき、クラスタサイズは最大32KiB(Windows NT系では64KiB)まで選択できることから求められる。ボリュームサイズはFAT32NTFSexFATなど他のファイル・システムへの移行により解決された。このボリュームサイズについては近年のフラッシュメモリでも同様である。

なおファイルシステムとは無関係に、一部のBIOSでは仕様によりボリュームサイズ2GB/4GBまでの容量の壁があった。例としては、BIOSが扱えるシリンダの最大値が4,096であることから、512×4096×16×63 = 2,113,929,216バイト(約1.96GiB)までしか認識できないケースがよく見受けられた。また、NEC PC-9821シリーズでも、おおむね1997年ごろまでの機種には、4.3GB超のHDDを接続するとマシンが起動しなくなるという不具合があった。(詳細はPC-9821シリーズの項を参照。)

ファイルサイズの制限

単一のファイルサイズの制限は、FAT16ファイルシステムで2GiB(NT系では4GiB)、FAT32では4GiB(マイナス1)までである。

FAT以外でもUNIX系OSにおいてファイルに関わるサイズを扱うソースコード内でint(32ビットデータ型モデル)を多用していた事による2GiB、4GiBの制限が多数あった[2]

4.7GBの容量を持つDVDや、数百GB以上のハードディスク、8 - 16GB以上のUSBメモリが一般化し、動画を中心とした大容量のデータを扱うようになって、この問題が顕在化してきた。

8GBの壁

IDEの拡張であるEIDE、さらにSCSI HDDでも「8GBの壁」といわれ、1998年頃までに発売されたPCに同様の問題があった。これは、PCのBIOSやSCSIコントローラに起因するものであり、HDD側には壁はない。

EIDE HDDやSCSI HDDでは、7.875GiB(約8.456GB、512×1024×256×63 = 8,455,716,864バイト、16,515,072セクタ、LBAでは24bit相当)を超える容量が認識されないという問題があった。これは「8GBの壁」といわれ、1998年頃までに発売されたPCではこの問題があり、Pentium II搭載以前のものに多い。

ただし、これはPCのBIOSのパラメータに起因する問題であり、HDD側にはやはりそのような壁はない。この8GBの壁は、BIOSのAPIレベルでLBA (28ビット) に対応した拡張INT 13hによって、BIOS側で認識できる最大容量は128GiB (約137GB) に引き上げられた。これは、拡張INT 13h自身がサポートするLBAは64bitで[3]、当時のATA HDD規格でサポートするLBAが28bitだったためである。

BIOS側がCHSでアクセスしてきた場合に、7.875GiBを超えるEIDE HDDは7.875GiBのジオメトリを返答するようになっており、Cylinder head sector=1023/255/63と返す(ただし、ごく一部のHDDでは返さないことがあった)。BIOSから正常にアクセスできるのは、HDDの先頭から7.875GiBまでの領域のみだが、これにより、LBA非対応のBIOSのマシンに接続しても、とりあえず認識され使用できるようにはなっている。その為、BIOSに依存せずにデバイスドライバが直接コントロールするOS(Windows 2000/XPやLinuxなど)では、OSが起動してデバイスドライバのコントロールに切り替わった後は7.875GiBを越える領域にも正常にアクセス可能である。デバイスドライバが直接コントロールするようになるまではBIOSを介してアクセスする為、当該HDDにOSを格納する場合には、BIOSにロードさせる範囲を先頭から7.875GiBまでの領域に収める必要がある。OSとデバイスドライバさえ対応していれば、48bit LBAのHDDも同様にして使用可能である。

この他に、一部のSCSIコントローラ[注 1]にLBA値を格納するレジスタが24ビットのものがあり、224以上のセクタ番号を扱えない。そのため、このようなコントローラで扱えるHDDの最大容量は8GiB(約8.4GB)までであるが、それを超える容量のHDDを接続した場合の挙動はコントローラではなくソフトウェアの実装に依存する。

32GiBの壁

これには2つの要因がある。

一つ目としては、Windows NT系で、FAT32形式にフォーマットできるボリュームサイズが32GiBまでに制限されていたことがある(すでにフォーマットされた、32GiBを超える容量のボリュームにはアクセスできる)。なお、FAT32自体は、512バイト/セクターのとき、2TiBまでサポートする。

もう一つの要因としては、AWARD BIOS Version 4.5xのバグがある。当該BIOSにおけるLBAの実装バグにより、BIOSからは26bit分のLBAしか扱えず、「32GBの壁」と呼ばれていた。約32GiB(65,536×16×63×512 = 33,822,867,456バイト)を超えるHDDを接続するとマシンが起動しなくなる。これを解決するには、修正されたBIOSを入手して、BIOSをアップデートする必要がある。HDDによっては、ジャンパピンの設定により約32GiBのHDDとして認識させることが可能な製品も存在する。なお、ATAカード経由でHDDを接続すればこの問題は回避できる。

128GiB (約137GB) の壁

ATA HDDではLBA導入後、しばらくはLBAのアドレス長が28ビットだったが、ATA/ATAPI-6で48bit LBAに拡張された。Maxtor (当時) がBigDriveと名付け、理論上は128PiB(約144PB)までのアドレッシングが可能となった。

48bit LBAに未対応の機器およびOSで、128GiB (約137GB) の壁として問題が起きた。おおよそ2002年以前に発売されたPCでこの壁がある。

2TiB(約2.2TB)の壁

ATAインターフェイスとしては128ペビバイトの管理が可能になったが、ハードディスクのMBRパーティションでは、1パーティションで管理できる総セクター数は32ビット(232 = 4,294,967,296セクタ)となり、総容量は2TiB(512×232 = 2,199,023,255,552バイト)までとなる[注 2]

また、Windows内部では、大容量ストレージへのコマンド発行はSCSI CDB (Command Descriptor Block) に抽象化されており、10バイトCDB (32bit LBA) を用いるWindowsでは、総容量2TiB超のドライブ(パーティションではない)を扱えない。

ドライブおよびパーティションの双方で2TiB超を扱うためには、GPT(GUIDパーティションテーブル)、および64ビットLBA(Windowsの場合16バイトCDB)の双方をサポートするOSが必要となる。GPTはLBAを64ビット(8バイト)で管理するため、64ビットLBA下での制限は512×264 = 8ZiBとなる。

Windows XP(x86版)以前では、GPTと64ビットLBAはサポートされない。また、GUIDパーティションからシステムのブートをさせる場合、Windows Vista SP1/Windows 7/Windows Server 2008 x64(64ビット版)以降のOSが必要である(EFIでないとブートできない)。2011年現在、x86版(32ビット版)のWindowsは、GUIDパーティションからの起動に対応していない。

バージョン2.4までのLinuxはGPTには対応していたが2TiB超のディスクには対応していなかった。[4]

これらはBIOS、OS依存であり、macOSLinuxFreeBSDSolarisなど各種のOSが既に最新版ではGPTに対応済みである。

2010年11月、2TiBを超える容量の3.5インチHDDが発売された[5]

なお、2TiBを超える容量に関して、ファイルシステム、OSによる制限が掛かる、あるいはスパンボリュームなど特定の機能により制限解除される場合や、特定のBIOSやコントローラ、デバイスドライバ等との非互換性[6]により利用できない場合もある。互換性のないシステムでは、例として、3TBのHDDが746GiBと認識されることがある[注 3][注 4]

BigSector

2TiBの壁とは直接の関係は無いが、米国の業界団体IDEMA[7]2006年に、HDDの物理ディスクセクタサイズを512バイトから4KiBに拡張する事を提唱している[8]。このWEBサイトは、"BigSector"[1] と名付けられている。HDDの物理セクターサイズを4KiBに拡張する事に関して、HDDメーカー側は、エラー訂正に必要な総ビット数は、セクターサイズを拡張すると減少する、など、512バイト単位の非効率性などを主張している。

Advanced Format Technology

実際には、Western Digital社が2009年10月にAFT ("Advanced Format Technology") と名付けて4KiB/物理セクターのモデルを発売したものが初となる。

この初期のモデルでは、多くのPC/AT機を祖とするシステムが、慣習的に63セクタ目から、最初のパーティションが開始されることから、実際の取り扱いセクタをひとつずらすジャンパピンが設けられ、同様にWindows XPでのパフォーマンス低下を抑制するための、調整ツールが頒布された。

LBAにより参照される論理ブロック (Logical Block) と物理セクター(1セクター512バイト)は伝統的に同一視されてきた。即ち、「物理セクターサイズ=512バイト」はMS-DOS時代から変わっておらず、既存のHDDコントローラー、ホストバスアダプタデバイスドライバ、BIOSやOS、さらにパーティションを直接操作するソフトウェアなどがこの前提で設計されている為、物理セクターサイズの変更はあらゆるコンポーネントとの非互換性が問題になる。

そこで、LBAの論理ブロックサイズ(論理セクターサイズ)は従来の512バイトから変更せずに、物理セクターサイズだけを4KiBに拡張する方法が取られた。すなわち、OSやコントローラー側とは従来通りLBAによる512バイト単位でデータのやり取りを行い、物理メディアとのやり取りは物理セクターサイズの4KiB単位で行う。これがAFT ("Advanced Format Technology") である。

Advanced Format TechnologyAFT (en) は、HDD側の物理セクターサイズが4KiBであっても、OS、コントローラーからはセクターサイズ512バイトのHDDとしてアクセスできるようにエミュレーションを行う。

デバイスの物理セクターサイズよりも小さい単位での書き込みの場合、ドライブ側でリード・モディファイ・ライトが行われる。そのため、特にパーティションの開始位置が4KiB単位の物理セクター境界からずれた場合に大きな性能低下を引き起こす。この性能低下は(殆どの製品が4KiB物理セクターである)SSDでも起こる。

ATAによりHDDの論理セクターサイズおよび物理セクターサイズを知ることができるため、OS側で、物理セクター境界からずれた書き込みをしないように調整する(リード・モディファイ・ライト、RMWの回避処理)ことができる。ただし、HDD側が正しく通知すること、および前述のような調整機能を備えたOSを利用することの双方が必要である。初期のAFTのHDDには正しく論理・物理サイズを通知せず、論理・物理セクターサイズ=512バイトだけを通知するものもあった。また、2010年11月現在、WindowsではAFTのRMW回避処理はVista SP2 / 7 RTM 以降でパッチでしか提供されていない。

2012年10月、マイクロソフトはセクターサイズが4096バイトのHDDについての分類および同社によるサポートに関して下記のように発表している[9]

  • 4K native
    • 物理・論理セクターサイズとも4096バイトのもの。
    • Windows 8/2012でサポートする。
  • Advanced Format (512E)
    • 物理セクターサイズ4096バイト、論理セクターサイズ512バイトのもの。
    • Windows Vista/7/2008/2008 R2/2012/8でサポートする。それ以外のOS(XPなど)については言及がない。
  • 512 native
    • AFT以前の従来のHDD。
    • 現時点(2020年4月)までのサポートに変化はない。

なお、サポート対象のHDDとOSの組み合わせであっても、サービスパックや修正パッチの適用が必要な場合があるので注意が必要である。

16TiBの壁

4KiB×232にあたる。4KiBはコンピューターによって都合のよい値であることが多い。

  • 32ビットLinuxカーネル

Linuxカーネルでは扱える最大ディスクサイズは ULONG_MAX×ページサイズ であるため、ILP32データモデルである32ビットLinuxカーネルをx86等の4KiBページサイズで動かしている場合16TiBが限界になる[10]

最大ファイルシステムサイズは 232×ブロックサイズ である。Linuxカーネルではページサイズ以下のブロックサイズしかマウントできないためx86等の4KiBページサイズでは16TiBになる。

メモリカード

デジタルカメラなどに使われるメモリーカードはこれまでFAT32に未対応で、規格上の最大容量は2GBとなっていた。しかし、デジタルカメラの高画素化や動画機能の充実によって、上限が2GBでは十分でなくなってきたことにより、さらなる大容量化が迫られていた。ファイルフォーマットの改良の結果、2006年に上限は32GBに改善されたことになるが、2008年には上限である32GB製品が登場した。

SDメモリーカード

従来型SDメモリーカードは上限が2GBであったが、2006年1月に最大32GBまで使用できるSDHCカードの仕様が策定された[11]。その後2008年1月にはSDHCの上限となる32GBモデルが発売されたことで、2009年1月に最大2TBまで使用できるSDXCカードの仕様が策定された[12][13]。フォーマットは下位互換性があることからexFATを採用。

SD系カードがメモリーカードの規格の中でデファクトスタンダードとなったため、SDHC/SDXCカードへの期待や需要が高まる一方、事実上、SDHCで容量の壁である32GBに達してしまった。2006年6月から2008年1月の約1年半余りという短期間でSDHCが容量の壁に達することは当初予想されていなかった。SDXCはムーアの法則を大きく上回るペースで媒体の容量増加が顕著な昨今でも、発表時点から最低でも5年間は容量の壁に達することはないとしている[14]。その後、2018年に上限が128TBのSDUCカードが制定された。

その他のメモリーカード

その他のメモリーカードでは、ファイルサイズ以外の問題から容量の壁に達する現象が起きている。

代表例がメモリースティックスマートメディアで、何れもFAT16の上限より低い128MBで容量の壁に当たってしまった。これらの原因は電気的仕様の問題で、これを解消すべくメモリースティック陣営は新規格となるメモリースティック PROを2003年1月に発表し、スマートメディア陣営もスマートメディアとは直接的な互換性のないxDピクチャーカードを2002年9月に発表した。

その後メモリースティック PROはSDHCと同様にFAT32の限界である32GBに達したことから、2009年1月に「高容量向け拡張フォーマット(仮称)」として発表し、同年8月に「メモリースティックXC」として仕様を公開した。しかし、メモリースティックを推進したソニーも2018年現在ではSDカード対応製品を発売しているため、あまり普及しなかった。

メモリ

主記憶の壁であるが、一般に、コンピュータ・アークテクチャやオペレーティング・システムの観点から、メモリ管理に論理層と物理層があることから、「論理的な壁」と「物理的な壁」におおざっぱに分類できる。たとえば、プロセッサの命令セット・アーキテクチャ(ISA)の設計上アドレッシング空間が32ビットであれば、プロセスが4Gより大きいデータを扱うのは面倒になるし(論理的な壁)、拡張バスのアドレスバスの幅が32ビットであれば、4Gより多いメモリを増設するのは面倒である(物理的な壁)。両者が、設計時点から見た将来をも見通してバランス良く設計されていることはまず無く、しばしばどちらかがどちらかの邪魔をする、といったようにして壁ができるし、一般ユーザはその両方の壁の組み合わせによって、大きな制限を受けたりすることもある。

マイコン時代以前

マイクロプロセッサ以前のコンピュータ、すなわち電子式コンピュータの黎明期から初期のメインフレームの時代には、まだ仮想化(仮想メモリ)も発達しておらず、設計時点で用意可能なメモリの物理量に合わせ、論理アドレスも設計されている、というコンピュータも多かった。これは、新しいコンピュータ毎に命令セットも新しく設計していたような当時には合理的な選択であったと言えるが、発売後にメモリが安くなり、またユーザからの要求でメモリを増やす際に当初の設計が「壁」になったような例もある。

1964年のIBM System/360以降、コンピュータの実装とは独立して、命令セットは長く引き続いて使われるものになったことから、命令セットの設計にもとづく壁、といったようなものが顕著となった。IBMのメインフレームでは、当初は32ビットのうち24ビットが有効なアドレスであったが、後に31ビット(32ビットではない)に拡張する際に巧妙な手法がとられた(詳細は 31ビット#31ビットアーキテクチャ を参照)。

また、ミニコンピュータの設計に関しては、ゴードン・ベルとW. D. Streckerによる回顧「Retrospective: what have we learned from the PDP-11 — what we have learned from VAX and Alpha」(doi:10.1145/285930.285934)の中で、彼らの以前の論文からよく引用される部分として「There is only one mistake that can be made in computer design that is difficult to recover from — not having enough address bits for memory addressing and memory management.」という記述を挙げている。

8ビット時代

初期のマイクロプロセッサの設計の発展は、以前の大型コンピュータやミニコンピュータの発展を、おおまかに見ればある程度はなぞっているが、メモリの設計という観点からは、当初からバイトアドレッシングを大前提としたものがほとんどであった、という点が大きく異なる。

一般に「Xビットコンピュータ」はアドレス空間などもXビットのことも多いが、8ビット(や、4ビット)ではアドレス空間としては狭すぎるため、4ビットマイクロプロセッサでは12ビット前後、8ビットマイクロプロセッサでは16ビットのアドレス空間とした設計が多い。そのため、8ビット時代には、しばしばいわゆる「64Kの壁」がいろいろなもので見られた。また、64Kを半々に分けて使う、といったような設計では「32Kの壁」となる。

1970年代には、64Kバイトにフルにメモリを実装したシステム、というのはまだコスト的に稀であったが、1980年代には続々と64Kでは足りなくなっていった。Z80を使ったパソコンの設計としては、VRAMをメモリ空間ではなく裏技を使った16ビットのI/O空間でアクセスしている例などがある。一般的な「壁」を超える手法としては、空間の一部または全部について、実メモリとの対応を切り替える「バンク切り替え」が多用された。

x86 16ビットから32ビット

この節では、IBM PCおよびNEC PC-98など、x86パソコンの例を挙げる。

8086

前述のように「Nビットマシン」と呼ばれるコンピュータにおいて、Nが比較的小さいマシンではアドレス空間をNより大きめに取るのが通例であるが、16ビットの8086の場合、物理アドレスを20ビットとして1MiBの空間があった。

しかし8086は、プログラムカウンタ(8086の用語ではインストラクションポインタ)などは16ビットとし、「セグメントレジスタ」と称する用途別(コード・データ・スタック・他)の数本のレジスタの内容を16倍(左に4ビットシフト)した値に、そこからのオフセットとして足し込んで20ビットのアドレスとする、という独特な方式(これは、コンピュータ・アーキテクチャで一般にセグメント方式と呼んでいるものとは全く異なるものであるため、多くの混乱の原因となっているが、Intelはそう名付けた。セグメント方式#x86も参照)とした。この設計は、多くの16ビットアドレスな8ビットプロセッサ用に存在していたプログラムを書き直すには便利な仕様であった反面、8ビット時代じみた「64Kの壁」をしばしば発生させる元凶にもなった。

8086におけるアドレッシングの例:

  • CS(コードセグメント)レジスタの値: 0x1234
  • IP(インストラクションポインタ)レジスタの値: 0x0100

このとき、(0x1234 << 4) + 0x0100 == 0x12440 番地が、命令がフェッチされる実アドレスとなる。

また、IBM PCをはじめとする多くのパーソナルコンピュータは、前半640KiBをメインメモリ用(コンベンショナルメモリ)とし、残りをメモリマップドI/OやBIOS ROM等のシステム用という設計とした(ハイパー98(のハイレゾモード)等のように、640KiBではなく768KiBまで広げた設計もいくつか見られる)。

この640KiBというサイズは、MS-DOSで普通に(コンベンショナルに)使えるメモリサイズの限界として壁として認識されるようになり、しばしば誤ってビル・ゲイツの言とされる(実際には、そのような発言をしたというような記録等は見つかっていない)「640 K ought to be enough for anybody.」というフレーズがある(q:en:Bill Gates#Misattributedを参照)。

より多いメモリを使うためには、コンベンショナルメモリの一部、あるいはシステム領域の一部を入れ替える、BMSハードウェアEMSという手法が取られた。また、1MiBもアドレス空間の壁として認識された。

以上のような8086の設計は、少し登場が後であるが68000が一部のバスは16ビットながらも、32ビットレジスタや24ビットの空間を持つ、余裕があるアーキテクチャとしたのと対照的と言える。

286

286は、本格的な32ビットマシンではなく16ビットマシンではあったものの、プロテクトモードはそれなりのメモリ管理システムを持っており、24ビットの空間(16MiB)があったが、それを活用できるパソコン用OSとしてはOS/2Windowsは広く普及するに至っておらず、MS-DOSでは前述の8086との互換性が重視されていたため、あまり活用されなかった。わずかに、A20線(en:A20 line)を有効にすることで、1MiBの壁を超えた先の64KiB(正確には (64Ki - 16)B )にアクセスできるというHMAが、互換性に大きな影響なく利用できることもあり、活用された。

DOSエクステンダPC-UNIXなどによる活用も可能であったが、標準でないことなどもあって、あまり広まらなかった)

PC-9801では、16MiBのうちの最後の1MiBをグラフィックシステム用に割当てた機種があったため[15]、その部分について連続して使えなくなる「16Mの壁」があった(起動時のメモリチェックで、少し表示位置がずれたり、「壁」を越えるタイミングでカウントアップがワンテンポ遅くなるものがあった)。

386以降

386は、プロテクトモードなどが完備した32ビットの、当時のメインフレームと比べても基本的な機能は揃っている本格的なコンピュータであり(メインフレームの64ビット化は1990年代末である)、論理・物理ともに32ビットで4GiBの空間があった。

さらに286とは違い、従来の8086のプログラムをそのまま動かすことが可能な仮想86モードを利用することで、MS-DOSでもEMB/UMB (XMS) あるいはEMSによって1MiBの壁の中であるが、前述のシステム領域(640K〜1Mの間)の「隙間」をユーザ用として多用できるようになり、デバイスドライバFEPの辞書を置いたり、RAMディスクやディスクのキャッシュなどに活用された。

プロテクトモードの本格的活用としては、最低スペックとして386以上のCPUの存在を前提にできる新規設計のパソコンであったFM TOWNSでは、標準としてTownsOSDOSエクステンダが含まれており、1Mの壁の無い環境が、ゲーム等、メモリを多用するアプリケーションに活用された。

一方、DOS/V機98では、前述のような互換性のために活用はなかなか進まなかったものの、386以降のプロセッサをCPUとしたマシンの普及は、後の、MS Windowsの特に広く普及した95や、やがてそれに置き換わるNT系の普及のための地均しであり、98においては98である必要性を喪失しDOS/V機に吸収消滅という終末への序曲でもあった(また、DOS/Vの文字表示の高速化、という点でも、98を不利にしていった)。

x86 32ビットから64ビット

前の節で述べたパソコンの、64ビット化の経過について述べる。

CPU側

80386以降のIA-32アーキテクチャ(x86、32ビット)が一般的となった以降、CPUの64ビットアーキテクチャ導入が徐々に進められ、x64アーキテクチャ(x86-64。AMD64およびIntel 64)が普及している。PCで主流の64ビット環境、x86-64への移行はx86の16ビットから32ビットへの移行に比べれば緩やかである。

次のようなx86の制限(壁)の抜本的な解決として、x86-64への移行が進みつつある。

物理メモリの容量
当初のPAEPSE36では最大64GiBまでしか対応できなかったが、x86-64拡張の際に改定され32ビットx86であってもPSE36では1TiBまで、PAEでは同CPUをx86-64として動かした際と同じ物理アドレスまで拡張された。x86-64では、現在、48ビット物理アドレス拡張により256TiBまで対応している。
仮想アドレス空間の容量
x86の32ビット環境では、32ビットフラットアドレスを採用し、1プロセスアプリケーション)が扱えるアドレス空間(メモリ量)の限界は32ビットで表せる4GiBであることが一般的である。x86-64アーキテクチャでは48ビットで、256TiBまでのメモリを扱うことが出来る。x86-64アーキテクチャでは将来的には52ビット、4PiBまで考慮している。なお、64ビット論理アドレスは16エクサバイト。論理アドレスはレジスタアドレッシングの空間であり、仮想空間とは異なる。

OS側

OS、アプリケーション側の対応としては、x86-64対応のWindows(いわゆる「64ビット版」)で、サポートアドレス空間が16TiBに拡大されている[16][17]。最近では、Adobe Photoshop CS4[18]など、サーバ用途以外でも64ビット対応が進みつつある。

Linuxの32ビット版 (x86) では、ディストリビューションやカーネル、設定(コンフィギュレーション)によって対応がまちまちであり、1GiB・4GiB・64GiBの壁がある。64ビット版(x86-64ないしAMD64)ではこのような問題はない。

現時点での壁

2016年現在の、主に32ビット時代の設計に由来する、64ビット環境に対する何らかの妨げになっている壁について解説する。

物理メモリの壁
PAE(物理アドレス拡張)は、CPUの使用可能な物理メモリの量を増やす機構である。PSE(ページサイズ拡張)およびPSE36も同様の側面を持ち、これらによって32ビットx86で対応できる物理メモリの量は当初の4GiBから64GiB以上に拡張された。しかしマーケティング上の理由やOS側の実装上の理由により64GiB以上を使えるOSはごく僅かしか無い。
2GiBの壁
32ビットWindowsアプリケーションでは、1プロセスごとの4GiBのアドレス空間うち、カーネルが2GiBを予約しており、アプリケーションが自由に使用可能なのは2GiBである。この壁に達してくるとマイクロソフトは主に2つの対処手段を打ち出した。1つはアドレスウィンドウ化拡張 (AWE)[19]である。4GBを超えるメモリを部分部分で切り替えながら読み書きする方法であり、MS-DOSの頃のEMSのようだという意見もある[20]。もう1つは、4-Gigabyte Tuning (4GT) の導入である。カーネルとアプリケーションのアドレス空間の配分を通常の2GiB-2GiBから、1GiB-3GiBに変更する手法である[16]。カーネルリソースが減少するため、サーバー用途(特にWebサーバー)には安定性の面から向かないという欠点がある。なお、64ビットWindows上では、4GT対応32ビットアプリケーションは4GiBほぼすべてアプリケーションが使用可能である[17]
4GiBの壁
ハードウェアのPAE対応とは無関係に、Windows XP/Vista/7の32ビット版では、カーネルのメモリマネージャーが4GiB以上の物理メモリを使用できない。すなわち、プロセスの仮想メモリ空間としても、4GiB以上の物理メモリにはアクセスしない。これはデバイスドライバの互換性を確保するための制限である[21]。なお、Windows Server(2000と2003の一部)では同じ32ビット版でも制限が緩和されているが、対応したデバイスドライバが必須である。いずれにせよ、1プロセスのアプリケーション空間は前述の「2GiBの壁」が残る。
3GiBの壁
x86向けのデバイスドライバは、4GiB内の物理アドレス空間のうち最初の方にあるメモリマップドI/O (MMIO) 用に割り当てられた空間を使用する。そのため、3GiB以上の物理メモリを搭載する場合、MMIO空間と干渉する場合がある。これは、該当部分のアドレスを回避するようにメモリの物理アドレス自体を変換するMemory Hole Remappingなどと呼ばれる手法で対処されている。Memory Hole Remappingはハードウェア(チップセット周辺)側の対応が必要であり、未対応のハードウェアでは物理メモリ容量がその分減少などする。またMemory Hole Remapping未対応のOSでこれを有効にすると互換性の問題からOSが停止する場合がある。また、上記「4GiBの壁」に該当するOSでは、Memory Hole Remapping対応とは無関係に、搭載された4GiBの容量のうちMMIO空間分が、プロセス用には利用できなくなる。未対応であればMMIO空間のメモリが見えなくなる。対応していても、これらのOSでは4GiBの壁を超えた部分にリマップされたメモリをプロセスに利用できない[22][23]

4GiBや3GiBの壁を超えたメインメモリを、ソフトウェア方式のRAMディスクとして活用する手法がある。これは、64ビット環境に切り替えずに、既存のハードウェア及びOSの環境の上で、4GiB/3GiBの壁のため利用できないメモリを有効活用する方法として、注目を浴びている[要出典]

x86以外

他にもたくさんの例があるが、ここではMacintoshの「8MiBの壁」とX68030の「12MiBの壁」を紹介する。

Macintosh

Macintoshでは、主にIIシリーズ(SE/30含む、IIvi・IIvx除く)でこの壁が顕著だった。IIシリーズでは、多くの機種でメモリを32MiBまで(動作保証外で128MiBまで)搭載できたが、System 6.0.xまでで使用できるのは8MiBまでであった。これは、アドレッシングモードを24ビットしかサポートしないOSの問題であるが(初代MacintoshのCPUである元祖68000MPUのアドレッシングが24ビットだったのが遠因にある)、一部機種ではSystem 7以降でも32ビットモードへの切り替えができないものがあった。これは機種搭載のROMの問題である。II・IIx・IIcxとSE/30で問題が起こり、それ以降のIIci・IIfx・IIsi(IIvi・IIvx含む)ではROMの内容が32ビットクリーンなためROMに起因する問題は起きない。なお除外したIIvi・IIvxではSystem 7.1以降でしか起動できないため、この壁はない。

その他の機種では、各機種の仕様によるものである。Portable・PowerBook 100では9MiBまで、LC・LCII・ClassicIIでは10MiBまで搭載でき、同容量がSystem 6.0.xから認識できる。

X68030

X68030では、メモリ・I/OマップをX68000と合わせるため、X68000と同様にI/OポートやVRAMを12MiB - 16MiBの範囲に配置した。そのため、メモリ空間が12MiBまでと16MiB以上で分断されてしまった(前述のMacは24ビットモードと32ビットモードを切り替えることによりメモリ・I/Oマップが変化する)。

今後懸念される容量の壁

脚注

注釈

  1. ^ 富士通MB89352など。
  2. ^ HDD側には2TiBの壁は存在せず、この壁は主にOS等に起因している。
  3. ^ 3TBのHDDの容量例は3,000,592,982,016.000バイトで、これから2TiB(2,199,023,255,552バイト)をマイナスすると746.520GiB(801,569,726,464バイト)になる。このようなシステムでは、内部処理において、LBAが32ビット (2TiB) でオーバーフローを起こしている。
  4. ^ PC等ではアップデート等により対応できる場合があるが、ハードディスク録画機などの組み込み機器ではメーカーのサポート・アップデートにだけ依存する。

出典

  1. ^ IDEディスク容量の壁について”. 2025年3月30日閲覧。
  2. ^ en:Large file support
  3. ^ BIOS Enhanced Disk Drive Services (EDD) (PDF)
  4. ^ LargeBlockDevices - IA64wiki” (2009年12月10日). 2017年7月8日閲覧。
  5. ^ 【平澤寿康の周辺機器レビュー】Western Digital「WD30EZRS」 ~世界初、容量3TBに到達した3.5インチHDD”. PC Watch. インプレス (2010年11月15日). 2025年3月30日閲覧。
  6. ^ http://support.microsoft.com/kb/981627/en-us
  7. ^ IDEMA | International Disk Drive Equipment and Materials Association”. 2025年3月30日閲覧。
  8. ^ HDD業界団体が標準セクター・サイズを4Kバイトに拡大,「Windows Vista」は対応予定”. 日経クロステック(xTECH) (2006年3月25日). 2025年3月30日閲覧。
  9. ^ http://support.microsoft.com/kb/2510009/en-us
  10. ^ [dm-devel] How to handle >16TB devices on 32 bit hosts ??” (2009年7月18日). 2017年7月8日閲覧。
  11. ^ 4GB以上の容量を実現するSDカード上位規格「SDHC」”. Impress PC Watch (2006年1月9日). 2011年7月20日閲覧。
  12. ^ 笠原一輝 (2009年1月13日). “2TBの大容量と300MB/secの高速を実現するSDXC”. 2009 International CESレポート【SDXC編】. Impress PC Watch. 2009年1月24日閲覧。
  13. ^ SD Association (2009年1月7日). “SDXC SIGNALS NEW GENERATION OF REMOVABLE MEMORY WITH UP TO 2 TERABYTES OF STORAGE” (PDF) (英語). 出版社. 2009年1月24日閲覧。
  14. ^ 笠原一輝 (2009年1月13日). “2TBの大容量と300MB/secの高速を実現するSDXC”. PC Watch 2009 International CESレポート【SDXC編】. インプレス. 2017年7月9日閲覧。 “フラッシュメモリがムーアの法則を上回る1年で倍になる速度で進化していることを考えても、2008年のSDHCカードが最大32GBとして2TBに到達するのは2014年という計算になる。今のペースが維持されると考えても今後5年間は大丈夫な計算だ。”
  15. ^ 詳細は藤波氏による http://hp.vector.co.jp/authors/VA003988/pc9801.htm#9 などを参照。
  16. ^ a b メモリ サポートと Windows オペレーティング システム”. Windows Hardware Developer Central. マイクロソフト (2005年2月9日). 2009年1月24日閲覧。
  17. ^ a b Memory Limits for Windows Releases” (英語). MSDNライブラリ. マイクロソフト (2009年8月27日). 2009年9月2日閲覧。
  18. ^ Shankland, Stephen; 編集部、ラテックス・インターナショナル (2008年4月3日). “アドビ、次期「Photoshop」を64ビット化--ただしWindows限定”. CNET Japan. 2009年3月22日閲覧。
  19. ^ http://msdn.microsoft.com/en-us/library/aa366527.aspx Address Windowing Extensions
  20. ^ デジタルアドバンテージ (1999年10月26日). “11. Windows 2000 Serverの概要 (4) アプリケーションサービスとAdvanced Server”. 特集: Windows 2000とは何か?. @IT. 2009年1月24日閲覧。
  21. ^ Windows Vista または Windows XP Service Pack 2 で [システムのプロパティ] ダイアログ ボックスおよびシステム情報ツールで表示される RAM のサイズが予想より小さい”. サポート技術情報. マイクロソフト (2008年4月2日). 2008年3月26日閲覧。
  22. ^ 4 GB の RAM が搭載されている場合、Windows Vista の システム情報 ダイアログ ボックスで報告されるシステム メモリが予想より小さい”. サポート技術情報. マイクロソフト (2008年6月13日). 2008年2月13日閲覧。
  23. ^ Windows Vista SP1 では、システムに 4 GB のメモリが搭載されている場合、システム メモリ (RAM) が 4 GB と報告される”. サポート技術情報. マイクロソフト (2009年3月22日). 2009年2月13日閲覧。

関連項目


容量の壁

出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/05/10 01:36 UTC 版)

ハードディスクドライブ」の記事における「容量の壁」の解説

詳細は「容量の壁」を参照 ハードディスク容量は常に拡大し続けている一方、古いファイルフォーマットOSBIOS等が対応できる容量には上限存在し、これが通常「壁」称される主なものとしては、512MB、540MB、1GB、2GB(FAT16最大値パーティション毎)、4GB、8GB(BIOS制限)、32GB(一部AWARD BIOS問題)、64GB(Windows98Fdisk問題修正プログラムがある)、128GB、137GB(Big Drive対応してない場合制限値)、2TB(FAT32最大値パーティション毎 およびMBR方式パーティションテーブルのセクタサイズ512バイトでの最大値)などがある。古いBIOSによる制限場合には、BIOSアップデートすることで解決する場合もあるが、メーカーパソコンではアップデートできない場合が多い(どこのメーカーBIOS使っているのか公開しないことが多いため。普通はAwardAmerican Megatrendsいずれかなのだがそれさえも非公開場合も多い)。 理論上は、128PB(Big Drive最大値)などにも壁が存在し今後順調に容量増加続いた場合、その容量到達した時点問題になることになる。 ドライブによっては、ジャンパピン設定等でHDD認識可能容量下げられるものもある。

※この「容量の壁」の解説は、「ハードディスクドライブ」の解説の一部です。
「容量の壁」を含む「ハードディスクドライブ」の記事については、「ハードディスクドライブ」の概要を参照ください。

ウィキペディア小見出し辞書の「容量の壁」の項目はプログラムで機械的に意味や本文を生成しているため、不適切な項目が含まれていることもあります。ご了承くださいませ。 お問い合わせ


英和和英テキスト翻訳>> Weblio翻訳
英語⇒日本語日本語⇒英語
  

辞書ショートカット

すべての辞書の索引

「容量の壁」の関連用語

容量の壁のお隣キーワード
検索ランキング

   

英語⇒日本語
日本語⇒英語
   



容量の壁のページの著作権
Weblio 辞書 情報提供元は 参加元一覧 にて確認できます。

   
ウィキペディアウィキペディア
All text is available under the terms of the GNU Free Documentation License.
この記事は、ウィキペディアの容量の壁 (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。 Weblio辞書に掲載されているウィキペディアの記事も、全てGNU Free Documentation Licenseの元に提供されております。
ウィキペディアウィキペディア
Text is available under GNU Free Documentation License (GFDL).
Weblio辞書に掲載されている「ウィキペディア小見出し辞書」の記事は、Wikipediaのハードディスクドライブ (改訂履歴)の記事を複製、再配布したものにあたり、GNU Free Documentation Licenseというライセンスの下で提供されています。

©2025 GRAS Group, Inc.RSS