FAT32

記憶装置の大容量化から、OSR2からFAT32がサポートされるようになり、FAT32対応と謳われたアプリケーションソフトもしばしば目にします。大きなディスク容量が要求される度に、FATは12から16そして32と変化して来ました。一般ユーザーがこのFAT32の恩恵を受けるのは、実質的にはWindows98からですが、現在の仕様がそのまま活かされれば500メガから2ギガの領域を確保する際、FAT32を採用するかどうかを選択できるようになります(当然ですが2ギガ超は自動的にFAT32となります)。またFAT16の領域をFAT32に変換することもできるため、ユーザーの選択範囲が広がります。しかし、逆に言うと、HDを有効に活用するには、FAT32のメリット・デメリットを知る必要が生じることになります。
FAT32の利点は、最大容量が増えること以外にもうひとつ存在します。クラスタサイズが小さくなるということです。クラスタとはファイルを扱う上での最小単位で、FATと言う管理方式では、1バイトのファイルを作っても1クラスタを消費します。大容量のディスクでは1クラスタが32768バイトになることもあり、1バイトのファイルを作成すると残りの32767バイトは未使用となります。これをクラスタギャップといいます。任意のサイズのファイルが多数存在する場合、クラスタギャップ≒クラスタ長×ファイル数÷2となります。つまり、クラスタギャップはクラスタ長に正比例するため、クラスタ長を短くするほどクラスタギャップは少なくなります。簡単に言うと、大雑把に扱っていたディスクをきめ細かく扱える、ということです。
メリットに比べれば微々たるものですがデメリットも存在します。(1)FAT領域そのものが大きくなる、(2)大きなファイルのアクセスが遅くなる、(3)旧OSからアクセスできない、などです。
(1)はドライブ構成そのものが変わるため単純にFAT領域が倍になるだけとは言い切れませんが、何れにしても全体的に見れば大したことではありません。
(2)は、HDなら問題は無いでしょう。気になるのはMOなどのリムーバブルディスクですが、現時点ではFAT32はリムーバブルディスクに未対応であり、Windows95で一般的に使われる2ギガ超のリムーバブル媒体がないため問題となっていません。DVD-RAMの登場によってこの問題の解決が迫られる訳ですが、DVD-RAMは仮想ドライブ扱いになるとの噂もあり今後のことはまだわかりません。
(3)はこれまでの拡張でも同様のことが言え、誰も文句は言わないでしょう。旧OSからアクセスする必要があるのならFAT32を使用しないだけのことです。
大体、以上のことを踏まえればFAT32にすべきかの判断を間違えることは無いでしょう。
アクセス速度の低下に関して、ハードディスクなら問題ないでしょうと言いましたが、実際に使い込んでいない者がただ推測で言ったに過ぎません。雑誌等のベンチマークの結果を基にすると、充分にメモリが実装(64メガ)されていれば0～10%程度の低下で済むようです。大量のデータをバックアップするような場合にはアクセス速度の低下を体感できますが、普段の作業ではわからないものと思います。キャッシュメモリが少ない古いハードディスク(大抵は容量が少ないのでFAT32にする必要はない)で実装メモリが少ない場合には50%の低下が起こるそうです。要するに、古いハード環境には使用しないことです。
1ドライブ2ギガの壁を破るための仕様としてのFAT32ですが、決して評判はよくありません。私にはその理由がよくわかりません。細かく見ていくと、良くできた仕様だと思います。

(1)FAT32の領域の中身は(FAT領域)

・何故、最大容量が2テラなのか
一般にFAT形式のドライブの最大容量は、クラスタサイズ×(データとして扱われる)FAT数となります。12ビットFATの場合0x000から0xFFFまでの4096のFATが扱えますが、FATIDが先頭の2つ分を使っているため最初は0x002となり(0x000は未使用クラスタを指します)、0xFF7は不良クラスタ、0xFF8から0xFFFはファイルの最終クラスタとなるため、計4085が有効となります。クラスタサイズの最大は32768バイトであるため32768×4085=133857280(約128メガ)となります。同様に16ビットFATでは32768×65525=2147123200(約2ギガ)となります。この計算でいくとFAT32では128テラとなるはずですが、仕様では2テラとあります。これは何故でしょう?
少し話しが逸れますが、DOS3.3は16ビットFATをサポートしながらも1ドライブの最大容量は128メガまでとされています。これは1ドライブのセクタ数が最大65536であるため、論理セクタサイズが512なら最大容量32メガ、1024なら64メガ、2048なら128メガとなります。DOS5になってセクタ数がロング値に拡張されたため16ビットFATの本来の最大容量2ギガがサポートされました。このときアブソリュートリード・ライトが拡張されたためDOS3.3用の一部のソフトがDOS5で動作しないといった現象が起きたことが記憶にある方も多いと思います。
要するに、DOS3.3時代はFATが扱い切れる最大の数字を他の要因が邪魔していた訳で、実は今回のFAT32も同様のことが言えます。DOS5以降の仕様でセクタ数はロング値で表されるため4ギガとなり、セクタサイズ512バイトをサポートする必要があり、最大は2テラとなります。このためFAT32では、容量に応じて18～26ビットを使用し残りは未使用としています。ここまで敢えて32ビットFATと言わずFAT32と言ってきたのは、このためです。
32ビットOS(DOSの互換性を除けば)となった今、未使用だからと言って決して詰めたりはしないのは、12ビットFAT時代に

    pos = buffer+(clus/2)*3;                          
    if (clus&1) {                                     
        next = (*(unsigned int *)(pos+1)) >> 4;       
    } else {                                          
        next = (*(unsigned int *)pos) & 0x0FFF;       
    }

などと言った処理をしてきた人なら理解できると思います。因みに、12ビットFATはDOS2.11時代の遺物(?)ですがフロッピーディスクが存在する限りなくなることはありません。
2テラバイトは現時点では、事実上の無制限と言ってよく、今後OSがバージョンアップされても暫くはこの形式を継続し、2テラバイトが壁になってきた時にはBPBを拡張して対応するものと思われます。FAT32はポテンシャルでは128テラまでサポートできるのですから。

(注意)DOSのバージョンはPC-98シリーズ用の数字です。

(2)FAT32の領域の中身は(BPB領域)

FAT32で確保した先頭のセクターをダンプした例を以下に示します。

ADDR 00 01 02 03 04 05 06 07-08 09 0A 0B 0C 0D 0E 0F :
------------------------------------------------------------------- 
0000 EB 58 90 4D 53 57 49 4E 34 2E 31 00 02 08 20 00 :?X信SWIN4.1   
0010 02 00 00 00 00 F8 00 00 3F 00 40 00 3F 00 00 00 : . ? @ ?      
0020 41 E0 3E 00 B5 0F 00 00 00 00 00 00 02 00 00 00 :A.> ｵ         
0030 01 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 :              
0040 80 00 29 E9 12 56 1D 4E 4F 20 4E 41 4D 45 20 20 : ). V NO NAME
0050 20 20 46 41 54 33 32 20 20 20 FA 33 C9 8E D1 BC : FAT32 .3ﾉ紗ｼ

FAT32のBPB領域は

位置	内容	備考
0000h～0002h	ジャンプ命令	ブートドライブの場合にここのコードが実行されます。
0003h～000Ah	ラベル	初期化を行ったOS名やバージョンが記入されます。 OSR2では「MSWIN4.1」となりそれ以前のWIN95では「MSWIN4.0」となる。
000Bh～000Ch	ドライブの論理セクターサイズ	通常は512(200h)バイトとなる。
000Dh	アロケーションユニットのセクター数	01h … 512バイト 02h … 1024バイト 04h … 2048バイト 08h … 4096バイト 64h … 32768バイト
000Eh～000Fh	メインFATの開始セクター番号
0010h	FATの組数	ハードディスクの場合、通常は2となる。
0011h～0012h	ルートディレクトリエントリ数	12/16ビットFAT用でFAT32では常に0となる。
0013h～0014h	全セクター数	セクター数がショートであらわされる場合の全セクター数。 FAT32では常に0となる。
0015h	メディアID	FATの先頭の1バイトと同じ値が入る。ハードディスクの場合、通常はF8hとなる。
0016h～0017h	FATレコード数	12/16ビットFAT用でFAT32では常に0となる。
0018h～0019h	1トラックあたりのセクター数	この3つはハードディスク情報を示す。
001Ah～001Bh	ドライブのヘッド数
001Ch～001Fh	不可視セクター数
ここまでは16ビットFATと互換がある。ここからはFAT32で拡張された。
0020h～0023h	FAT32ドライブの全セクター数
0024h～0027h	FAT32ドライブのFATセクター数
0028h～0029h	アクティブFAT/ミラーリングフラグ	通常は0000hが入っており、ミラーリングを行うと Bit7がONになり、Bit3～0にアクティブFAT番号が入る。
002Ah～002Bh	ファイルシステムバージョン	現在は0000h。今後の拡張のための予約エリア。
002Ch～002Fh	ルートディレクトリの開始クラスタ位置	フォーマット直後は00000002h(FATのすぐ後ろ)を指し意図的に移動しない限りはこのままとなる。
0030h～0031h	ファイルシステム情報のセクター位置	FSINFO(ファイルシステム情報)のセクター位置を指す。
0032h～0033h	予備ブートセクターのセクター位置
0034h～003Fh	予約エリア
0040h	起動ドライブ情報	80h … 起動可能ドライブ 00h … 起動不可ドライブ
0042h	拡張IPLフラグ	29hの場合、ボリュームシリアル番号を持つ。
0043h～0046h	ボリュームシリアル番号
0047h～0051h	ドライブ名
0052h～0059h	ファイルシステムタイプ	FAT32またはFAT16の文字が書き込まれる。

(3)ルートディレクトリの扱いはどうなったか

ご存じと思いますが、これまでのFAT方式ではルートディレクトリに置けるファイルの数に制限がありました。VFATでは1つのファイルで複数のディレクトリエントリ領域を使うため、ルートディレクトリに長い名前のファイルを置くと忽ちルートディレクトリのエントリ数の限界に達してしまいます。FAT32ではこの点も改善しています。
ルートディレクトリの開始クラスタ位置をBPBで持つため、ルートディレクトリエントリもユーザーエリアに取られ、意図的に変更しなければユーザーエリアの先頭となります。1クラスタに収まらない場合は、サブディレクトリ同様に別のクラスタを使用します。この時、通常は不連続になりますが何ら問題はありません。因みに、OSR2のデフラグはこれらをユーザーエリアの先頭に集めます。
ひとつ、厄介な問題があります。CHKDSK等でのルートディレクトリエントリの扱いは、1クラスタだけはシステムエリア、他はユーザーエリアとなります。これまでの互換性を保つためとも言えますし、初期化直後にはユーザーエリアが全て未使用扱いとするためとも言えます。何れにしても大変解りにくい仕様になってしまいました。とは言え、実用性で考えれば、大きな改善と言えます。

(4)リムーバブルディスクはFAT32に対応できないのか?

現段階ではFAT32はリムーバブルディスクには未対応となっています。その最大の理由は、ドライブ情報の管理を従来の方式からFileSystemInfo(以降FSInfoと言う)に記録する方式に変更したからです。従来は起動時にFATの内容をスキャンして空き容量を求めていたのを、高速化のためFSInfoを参照しDPB情報として使用するのです。OS稼働中にディスクへの書き込みやファイルの削除等が行われた場合には、DPBに反映させ(メモリ上なので速度は問題にならない)、OSの終了時にFSInfoとして書き戻すのです。異常終了の後、デフォルトではスキャンディスクが自動的に行われるのはこのためです。何時取り出されるかわからないリムーバブルディスクはFSInfoの書き戻しができず、そのため未対応としたのです。
DOSモード(MS-DOS7.1以降)でもFAT32ドライブにアクセスできますが、OSのシャットダウンのような操作のないDOSモードで正常にアクセスできるのでしょうか?実は、DOSモードではDPB情報が変わる度にFSInfoを書き戻しており、アクセス中に電源を切らない限り大丈夫なのです。リムーバブルディスクでもこの方式を採用すれば何ら問題はないわけですが、毎回FSInfoを書き戻すという行為が、媒体によっては大変な処理速度の低下を招きます。従来の互換のために存在するDOSモードが遅いと言われるのは構わず、これからの時代をにらんだFAT32が遅いと言われることには抵抗があるようです。FAT32は現状で2テラ、ポテンシャルでは128テラの容量を扱えます。技術革新は確実に続いて行くでしょうが、それでもあと10年～15年は使える仕様なのです。リムーバブルディスクの扱いは今後のことを考慮してかなり慎重に検討してもらいたいものです。
Windows98のベータ版では、コントロールパネル-システム-パフォーマンス-ファイルシステムにリムーバブルディスクという項目が追加され、ここでファイル書き込み後にFSInfoを書き戻すかどうかの設定ができるようです。OS全体での設定となりますが、目的の異なる(速さを重視したり、容量を重視したり等)複数のリムーバブルディスクを使い分けることも今後は充分考えられるため、ドライブのプロパティでドライブ毎に設定可能にすべきではないでしょうか。また、何とかHDと同じように扱えないかと考えて見ましたが、ユーザーにある程度負担をかけていいなら、リムーバブルディスクの媒体の抜き差し以外にOSの画面上でマウント・アンマウントを行うという手もあります。FAT32のリムーバブルディスクは媒体を挿入しただけではアクセス出来ないようにしておき、画面上でマウントをすると、FSInfoのチェックを行い、この間は可能なものは媒体をロックし、以降HDと同じ様に扱います。アンマウントされるとFSInfoを書き戻し、ロックを解除し可能なものはイジェクトも行います。これは、あくまでひとつの例ですが、いろいろな方式の中から、ユーザーが選択できるようにしておけば問題ない(今後の変化にもそれで対応できる)と思います。
何れにしても、リムーバブルディスクがFAT32に「対応できない」のではなく「対応させていない」のが現状で、仕様が固まれば何時でも対応するのです。DVD-RAMが実用段階になってきた現在、解決が急がれます。

(5)ディスクを直接読み書きできるか?

OSR2からサポートされたFAT32ですが、一般ユーザーにとっては、一部のディスク関連のツールを使う際にOSR2対応のもの(今後はWindows98対応という肩書きになるかも知れません)を使えば、特に気にせず今まで通りで問題無さそうです。開発者の場合も、WindowsのAPIを使用していればFAT32に自然対応するはずです。問題はMSーDOSでアブソリュートリード・ライトを使っていたものがどうなるかです。MSーDOSのファンクションはOSR2でもまた拡張され、その中にアブソリュートリード・ライトも含まれています。動作中のバージョンを調べ、MSーDOS7.1(以降)なら拡張ファンクションを使えばいいわけです。つまりMSーDOSレベルで考えると「FAT32に対応する」=「MSーDOS7.1に対応する」ことと言えます。ひとつ間違うと1ドライブのデータが全てなくなる危険性もありますので、SETVERなどが使用されていたらはじいた方が無難です。余談ですが、バージョン取得のファンクションは、バージョンナンバーを3000hではAXに、3306hではBXに返します。何れの場合も上位と下位が逆だったら、レジスタの内容が大きいほど新しくなり比較が1回で済むのですが、この仕様では「7.1以降」を判定するにはメジャーナンバーとマイナーナンバーを別々に見なければなりません(レジスタの内容を入れ替えるという手もありますが)。以前から不便に感じていたことが、MS-DOS全盛期ではなくこんな時期になってから露呈するとは何とも奇妙です。
新しく拡張されたファンクションの最大の特徴は、書き込みの際にFAT・ディレクトリ・その他を指定する必要があることです(読み込む場合はそのような指定はありません)。ファイル一覧をソートして書き込むようなツールの場合は書き込む領域の内容が予めディレクトリだと知っているのでこういった仕様でいいのでしょうが、ドライブイメージを丸ごと書き込むような場合は、まず、拡張DPB情報を取得しFAT領域とデータ領域を区別する必要があり、データ領域を書き込む際にはクラスタ毎にFATの内容を確認する必要が生じます(FAT・ディレクトリ・その他を順番に指定してどれかひとつでも書き込みに成功すればいいという方法も考えられますが)。ディスクは直接読み書きせずOSに任せろと言わんばかりです。ただし、現時点では、これらの指定は不要で、今後も指定することは無いかも知れません(企画倒れの可能性あり)。
今までのアブソリュートリード・ライトはどうなったか気になります。マイクロソフトの立前は、公開ファンクションは今後もサポートし、非公開ファンクションは保証しないようです。この考えですとint25h・26hは公開ファンクションであるためサポートされているはずです。これに関してはテストプログラムまで作っていろいろ試しましたが、OSの保護の問題を除けば、実はOSR2でも相変わらずサポートされています。指定するセクタ番号が65535以下なら古いアブソリュートリード・ライトも動作します。従って、FDならMS-DOS3.3時代のものが、HDでも書き込みしなければMS-DOS5～6.2時代のものが動作する期待は充分持てます(他の要因で動作しないことも考えられますので一概には言えませんが)。
Windows98にはバックアップウィザードというものが加わるとのことですし、Windows用のソフトが充実した現在、2ギガ超の領域に対してはMS-DOS用ツールは用いない、と考えたほうがよさそうです。

(6)FAT32の経緯

FAT32についていろいろと話してきましたが、私がFAT32に拘るのには理由があります。MS-DOS時代からディスクBIOSやアブソリュートリード・ライトを使用したプログラムを作ってきましたが、それらがまだ完全には過去のものになっていないのです。
Windows95にとってMS-DOSは互換性のためにサポートしているという扱いで、完全サポートと言い切れないのが話しを少々難しくしています。MS-DOSが何度もバージョンアップされていった過程の中で、完全上位互換を理想としつつも時には仕方なくこれを破ってきました。ユーザーは過去のソフトウェア資産が継承出来ない危険性を僅かに感じながらも、大抵はなんとかなるであろうという楽観的な立場でいます。
Windows95がまだ「シカゴ」と呼ばれていたころ、FATが拡張されFAT32になると、密かに噂されていましたが、蓋を開けてみるとFAT32ではなくVFATというファイルシステムになっていました。このVFATが考案された背景にはインターネットの普及があります。インターネット時代にこれまでの8.3形式では不都合と考えたからで、この不都合が1ドライブ2ギガまでという不都合よりずっと大きいと判断したのでしょう。余談ながらVFATは、UNIXやマックOSに少しでも近づけたいという要求と、これまでの8.3形式を完全サポートするという2つの要求を実現するために随分汚い仕様になってしまいましたが、FAT32でもそのまま用いられ、今後暫くは変わらないものと思われます。また、NTはどうしてもWindows95より上に位置付けたいらしく、小文字の扱いでVFATの仕様を拡張しています。話しを元に戻し、もし、Windows95(MS-DOS7.0)になった時点でFAT32をサポートし、ディスクBIOSやアブソリュートリード・ライトを使用したプログラムは動作しないと正式アナウンスしていたらどうでしょう?ユーザーにとってはその方が分かり易かったはずで、このことが不服でWindows95は使わないなどと言い出す人はいなかったでしょう。Windows95は以前のOSとは違うという印象をユーザーに与えて登場したのです。Windows95初期バージョンでFAT32が実現できなかったのは、開発する人員や時間の問題が大きいと私は推測します。
Windows95になってアブソリュートリード・ライトという、相対セクタ番号を指定して読み書きする機能に制限が付きました。読み込みはできても書き込みはできないのです。ファイラーソフトにファイルのソート機能がありますが書き込むことができないのはこのためです。OSR2ではFAT32に拡張されたことに伴い、アブソリュートリード・ライトは拡張ファンクションとして新たに用意されました。
Windows95初期バージョンでロングファイル名がサポートされ、OSR2でFAT32がサポートされと、複数のバージョンを混在したいユーザにとっては煩雑な要因が増えてしましました。かくして、Windows98を導入後も、Windows95の領域がOSR2以降かどうかを意識する必要があります。開発者にとっても、随分複雑で不可解な内部仕様を持つファイルシステムになってしまいました。機能拡張の成り行きを知りつつその都度理解してきた私のような者にはまだ納得できる(いやいやながら)のですが、これから勉強しようとする人たちは大変です。開発者でもシステムの根幹に携わるケースはほとんどなくなるから問題ないかも知れませんが。私も興味は持ち続けるでしょうがあまり取り越し苦労はしたくありません。これ以上のことを求めると、仮想ドライバを自作する必要がありそうですが、現在の私にそれだけの力はありません。私なりのアプローチを続け、新たな進展があればそのときにこの話題を出すかも知れませんが、ここで一旦FAT32の話は終わりにしたいと思います。
蛇足ながら、ディスク関連の便利なツールが幾つか市販されています。OSが複雑化し、ディスクが大容量化した現在、安全にディスクを扱いたいのならこうしたツールを推奨します。

戻る