なぜSDHCは32GB止まりなのか、そのトリック

  • 投稿日:
  • 更新日:2016/06/10
  • by
  • カテゴリ:

32GB以上のSDHCカードがないのはなんで?

SD(HC)カードでは、ファイルシステムのフォーマットが物理的に制限されているわけではありません。 そのため、FAT16/2GBという規格のSD(SDHCではない)カードに、FAT16の規格を越える4GBサイズのものがありました。また、既存のSD(HC)カードに、規格以外のフォーマットをかけることも可能です。

SDHCが採用しているFAT32の論理上限は2TBなので、ソフト的な観点からは32GBを越えるカードも可能です。 しかし、実際には売られていません。なぜでしょう。

と思っていたら、英語版Wikipediaに情報がありました。

SDカードの仕様に答えが

SDカードの仕様では、カードに128ビットのIDが入っています。 HCではないSDカード(仕様1.x)では、このうち12ビットがメモリクラスタの数(1~4,096)、3ビットがクラスタあたりのブロック数(4, 8, 16, 32, 64, 128, 256, 512)を表しています。 SDカード1.xのうち、古い仕様では、ブロックサイズが512バイト固定のため、最大容量は次のように求められます。

4,096(メモリクラスタ数) x 512(ブロック数/クラスタ) x 512(ブロックサイズ) = 1GB

より新しい1.xの仕様では、上記のIDフィールドにブロックサイズを表す4ビットの値を持って1,024および2,048バイトをサポートするようになり、1GBを越えるカードを扱えるようになりました。 しかし、これによりデバイスによっては1GBを越えるカードを読めないことも出てきました。 例えば、私の使っていたVodafoneの705SHはmicroSDカードをサポートしていますが、1GBまでのカードしか認識しません。 これなどは、おそらくこの古い仕様が原因ではないかと思います。

さて、SDHC(仕様2.0)では、メモリサイズを22ビットのフィールドで表します。 値は512kBの倍数です。 しかし、現状では22ビットのうち16ビットしか使われていません。 すなわち、フィールドの最大値は65,536 (16ビットで表せる数の上限)となり、

512(kB) x 65,536 = 32GB

となります。 これが「32GB上限」のトリックです。

22ビットをフルに使うと、最大値は

512(kB) x 65,536 x 64(追加の6ビット分) = 2,048GB

となり、FAT32の論理最大の2TBまでサポートできることがわかります。

もちろん今これを行えば、4GBのSDカードのように互換性の問題も抱えることにはなるのですが、規格上はサポート可能にしておきながら、なぜ制限してしまったのでしょうか。

ちなみに、Windows XPが32GBを越えるFAT32のフォーマットを行わないのは、単にマーケティング上の理由です(NTFSに誘導したいため)。SDHCカードが 32GB止まりであることとは、おそらく何の関係もありません。SDHCカードにNTFSなんか採用したら最後、激しくMicrosoft縛りがかかるば かりか、アクセスするためのソフトウェア・ファームウェアが複雑になりすぎて実用にならないでしょう。いくらSDカードアソシエーションのメンバにMicrosoftが入っているからといって...ねぇ。

なお、SD(HC)カードおよびホストアダプタを製造販売するには、SDアソシエーションのメンバになる必要があり、メンバに課される年会費は$1,500、加えて製造販売のためのロイヤリティは年$1,000です。まぁ、この手の会費としては格安ともいえます。そのせいか、SDアソシエー ションのメンバ企業は非常に多く、「何でこの会社が?」というような企業もメンバに入っています。でも、意地でもソニーは入っていません

SDHCは登場からあっという間に最大容量の32GBに達し、 その32GBのSDHCカードが値下がりし始めています

SSDの代わりとしての利用も期待できるわけですから、早いところ何とかして欲しいものです。

FAT32の限界

FAT32の仕様自体は2TBまでサポートしているのは上記のとおりですが、以下の制限があります。

1ファイルのサイズは4GBまで

これは良く知られていますね。 理由は、ファイルの情報が格納されるディレクトリエントリにある (詳しくはこのページのDirectory Entry参 照)ファイルサイズのフィールドが32ビット(4バイト、DWORD)分しかないためです。 FATのクラスタチェインだけを考えれば4GBを越えるファイルを表現することもできますが、ファイルサイズフィールドとの不整合が発生するため、アプリケーション誤動作の原因になりますし、高レベルAPIではエラーになる可能性があります。

容量が大きくなるにつれ、いわゆる「デフラグ」や空きスペースの計算量が極めて大きくなる

FATは、容量が大きくなるとフラグメンテーションが発生しやすいという問題はよく知られていますね。

ではなぜ計算量が大きくなるかというと、FATでは領域がクラスタ単位で管理されているFile Allocation Table(だからFAT)を基にして動作するためです。FAT32では、クラスタごとに32ビット(4バイト)の情報を持っています。

FATの各エントリは、次のクラスタが何番なのか、ファイルの最後なのか、利用されていないのか、不良なのかなどの情報を表しています(リンクリスト)。これが、FAT32では28ビット分まで使われるので、最大容量まで使い切ると228エントリ存在することになり、FAT領域の大きさは

4(バイト/エントリ) x 228(エントリ) = 1GB

という容量になってしまいます。空き容量を計算するために1GBの読み込みを行うのは、FATが主に使われている組み込み分野はおろか、現状のPCでも結構つらい作業でしょう。

exFATは解決策になるか

これらの解決策として、exFATが提案されていますが、いろいろ技術的な事情(HDDには使えない、Windows XPでも使えない)や大人の事情(ライセンスが不透明、仕様が公開されていない)から、そう簡単には現在のFATの代替にはならないでしょう。

こちらもよく読まれています