容量の壁
ディスク
補助記憶装置（ハードディスクやSSDなど）に関与する容量の壁の原因には、ATAなどインターフェイスや、OSのファイルシステムなど、様々なものがある。 
場合によっては、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までのパーティションを管理することができた。
2GiB/4GiBの壁
ボリュームサイズの制限と、ファイルサイズの制限がある。
ボリュームサイズの制限
ファイルシステムにFAT16を用いた場合のボリュームサイズの最大値は、2GiB（NT系では4GiB）までとなる。最大クラスター（アロケーションユニット）総数は16ビットで、その内最大65,524までが領域として使用でき、クラスタサイズは最大32KiB（Windows NT系では64KiB）まで選択できることから求められる。ボリュームサイズはFAT32やNTFS、exFATなど他のファイル・システムへの移行により解決された。このボリュームサイズについては近年のフラッシュメモリでも同様である。
なおファイルシステムとは無関係に、一部の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、FAT32では4GiB（マイナス1）までである。
FAT以外でもUNIX系OSにおいてファイルに関わるサイズを扱うソースコード内でint（32ビットデータ型モデル）を多用していた事による2GiB、4GiBの制限が多数あった。
4.7GBの容量を持つDVDや、数百GB以上のハードディスク、8 - 16GB以上のUSBメモリが一般化し、動画を中心とした大容量のデータを扱うようになって、この問題が顕在化してきた。
8GBの壁
IDEの拡張であるEIDE、さらにSCSI HDDでも「8GBの壁」といわれ、平成10年（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 Extensionによって、BIOS側で認識できる最大容量は127GiB（約137GB）に引き上げられた。これは、INT 13H Extension自身がサポートするLBAは64bitで、当時の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コントローラにLBA値を格納するレジスタが24ビットのものがあり、2²⁴以上のセクタ番号を扱えない。そのため、このようなコントローラで扱える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を接続すればこの問題は回避できる。
127GiB(約137GB)の壁
ATA HDDではLBA導入後、しばらくはLBAのアドレス長が28ビットだったが、ATA/ATAPI-6で48bit LBAに拡張された。Maxtor（当時）がBigDriveと名付け、理論上は128PiB（約144PB）までのアドレッシングが可能となった。
48bit LBAに未対応の機器およびOSで、127GiB（約137GB）の壁として問題が起きた。おおよそ2002年以前に発売されたPCでこの壁がある。
2TiB(約2.2TB)の壁
ATAインターフェイスとしては128ペビバイトの管理が可能になったが、ハードディスクのMBRパーティションでは、1パーティションで管理できる総セクター数は32ビット（2³² = 4,294,967,296セクタ）となり、総容量は2TiB（512×2³² = 2,199,023,255,552バイト）までとなる。
また、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×2⁶⁴ = 8ZiBとなる。
Windows XP（x86版）以前では、GPTと64ビットLBAはサポートされない。また、GUIDパーティションからシステムのブートをさせる場合、Windows Vista SP1/Windows 7/Windows Server 2008 x64（64ビット版）以降のOSが必要である（EFIでないとブートできない）。平成23年（2011年）現在、x86版（32ビット版）のWindowsは、GUIDパーティションからの起動に対応していない。
バージョン2.4までのLinuxはGPTには対応していたが2TiB超のディスクには対応していなかった。
これらはBIOS、OS依存であり、macOS、Linux、FreeBSD、Solarisなど各種のOSが既に最新版ではGPTに対応済みである。
2010年11月、2TiBを超える容量の3.5インチHDDが発売された。
なお、2TiBを超える容量に関して、ファイルシステム、OSによる制限が掛かる、あるいはスパンボリュームなど特定の機能により制限解除される場合や、特定のBIOSやコントローラ、デバイスドライバー等との非互換性により利用できない場合もある。互換性のないシステムでは、例として、3TBのHDDが746GiBと認識されることがある。
BigSector
2TiBの壁とは直接の関係は無いが、米国の業界団体IDEMAが平成18年（2006年）に、HDDの物理ディスクセクタサイズを512バイトから4KiBに拡張する事を提唱している。このWEBサイトは、"BigSector"と名付けられている。HDDの物理セクターサイズを4KiBに拡張する事に関して、HDDメーカー側は、エラー訂正に必要な総ビット数は、セクターサイズを拡張すると減少する、など、512バイト単位の非効率性などを主張している。
メモリカード
デジタルカメラなどに使われるメモリーカードはこれまでFAT32に未対応で、規格上の最大容量は2GBとなっていた。しかし、デジタルカメラの高画素化や動画機能の充実によって、上限が2GBでは十分でなくなってきたことにより、さらなる大容量化が迫られていた。ファイルフォーマットの改良の結果、2006年に上限は32GBに改善されたことになるが、2008年には上限である32GB製品が登場した。
SDメモリーカード
従来型SDメモリーカードは上限が2GBであったが、平成18年（2006年）1月に最大32GBまで使用できるSDHCカードの仕様が策定された。その後2008年1月にはSDHCの上限となる32GBモデルが発売されたことで、2009年1月に最大2TBまで使用できるSDXCカードの仕様が策定された。フォーマットは下位互換性があることからexFATを採用。
SD系カードがメモリーカードの規格の中でデファクトスタンダードとなったため、SDHC/SDXCカードへの期待や需要が高まる一方、事実上、SDHCで容量の壁である32GBに達してしまった。2006年6月から2008年1月の約1年半余りという短期間でSDHCが容量の壁に達することは当初予想されていなかった。SDXCはムーアの法則を大きく上回るペースで媒体の容量増加が顕著な昨今でも、発表時点から最低でも5年間は容量の壁に達することはないとしている。その後、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パソコンの例を挙げる。
286
286は、本格的な32ビットマシンではなく16ビットマシンではあったものの、プロテクトモードはそれなりのメモリ管理システムを持っており、24ビットの空間（16MiB）があったが、それを活用できるパソコン用OSとしてはOS/2やWindowsは広く普及するに至っておらず、MS-DOSでは前述の8086との互換性が重視されていたため、あまり活用されなかった。わずかに、A20線（en:A20 line）を有効にすることで、1MiBの壁を超えた先の64KiB（正確には (64Ki - 16)B ）にアクセスできるというHMAが、互換性に大きな影響なく利用できることもあり、活用された。
（DOSエクステンダやPC-UNIXなどによる活用も可能であったが、標準でないことなどもあって、あまり広まらなかった）
PC-9801では、16MiBのうちの最後の1MiBをグラフィックシステム用に割当てた機種があったため、その部分について連続して使えなくなる「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では、標準としてTownsOSにDOSエクステンダが含まれており、1Mの壁の無い環境が、ゲーム等、メモリを多用するアプリケーションに活用された。
一方、DOS/V機や98では、前述のような互換性のために活用はなかなか進まなかったものの、386以降のプロセッサをCPUとしたマシンの普及は、後の、MS Windowsの特に広く普及した95や、やがてそれに置き換わるNT系の普及のための地均しであり、98においては98である必要性を喪失しDOS/V機に吸収消滅という終末への序曲でもあった（また、DOS/Vの文字表示の高速化、という点でも、98を不利にしていった）。
x86 32ビットから64ビット
前の節で述べたパソコンの、64ビット化の経過について述べる。
OS側
OS、アプリケーション側の対応としては、x86-64対応のWindows（いわゆる「64ビット版」）で、サポートアドレス空間が16TiBに拡大されている。最近では、Adobe Photoshop CS4など、サーバ用途以外でも64ビット対応が進みつつある。
Linuxの32ビット版 (x86) では、ディストリビューションやカーネル、設定（コンフィギュレーション）によって対応がまちまちであり、1GiB・4GiB・64GiBの壁がある。64ビット版（x86-64ないしAMD64）ではこのような問題はない。
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マップが変化する）。