FatFsモジュールアプリケーションノート

ポーティングの際に配慮すべきこと

移植の際の前提条件

FatFsモジュールは移植性に関して次の点を前提としています。

処理系はANSI C準拠であること。
FatFsモジュールはANSI C(C89)準拠で記述されているので、普通のCコンパイラなら特に処理系依存になる点はありません。
char/short/longのサイズは、それぞれ8/16/32ビットで、intは16または32ビットであること。
これについても、まっとうな処理系なら問題ないはずです。FatFsモジュールで使用されるサイズを明示する整数型が integer.h 内で定義されていますが、既存の定義と衝突した場合はユーザによって解決されなければなりません。

システム構成

下に示す依存関係図は、FatFsモジュール利用の組み込みシステムにおける代表的な構成を示します。

システム構成図

(a) FatFs用に書かれたディスクモジュールがある場合は、そのまま追加するだけです。 (b) しかし、多くの既存のディスクモジュールはそのAPIをFatFsに合わせるため、グルー関数が必要になるでしょう。

functional diagram

ユーザの作成する関数

必要なのはFatFsモジュールの要求するディスク関数を用意することだけで、それ以外にすることはありません。既に動作しているディスクモジュールがあるなら、そのAPIをFatFsに合わせるかグルー関数を介してつなぐだけで済みますが、無い場合はほかから移植するか最初から書くかする必要があります。定義されている全ての関数が常に必要なわけではありません。例えば、リードオンリー構成では書き込み系関数は必要ありません。次の表に構成オプションと要求される関数の対応を示します。

必要な関数	必要となる条件	備考
disk_status disk_initialize disk_read	常時	ffsample.zip (サンプル) その他web上に多数
disk_write get_fattime disk_ioctl (CTRL_SYNC)	_FS_READONLY == 0
disk_ioctl (GET_SECTOR_COUNT) disk_ioctl (GET_BLOCK_SIZE)	_USE_MKFS == 1
disk_ioctl (GET_SECTOR_SIZE)	_MAX_SS != _MIN_SS
disk_ioctl (CTRL_TRIM)	_USE_TRIM == 1
ff_convert ff_wtoupper	_USE_LFN >= 1	option/unicode.c
ff_cre_syncobj ff_rel_grant ff_req_grant ff_del_syncobj	_FS_REENTRANT == 1	option/syscall.c (サンプル)
ff_mem_alloc ff_mem_free	_USE_LFN == 3	option/syscall.c (サンプル)

限界値

FATタイプ: FAT12, FAT16, FAT32。
同時オープンファイル数: 無制限。(利用可能メモリによる)
ボリューム数: 最大 10。
ファイルサイズ: FAT規格に依存。(最大 4G-1バイト)
ボリュームサイズ: FAT規格に依存。(最大 2Tバイト(512バイト/セクタ時))
クラスタサイズ: FAT規格に依存。(最大 64Kバイト(512バイト/セクタ時))
セクタサイズ: FAT規格に依存。(512～4096バイト)

メモリ使用量

次の表にいくつかのターゲットにおけるメモリ使用量の例を示します。テスト時の構成オプションはその下の通りです。数値の単位はバイトで、Vはボリューム数、Fは同時オープンファイル数を示します。コンパイラの最適化オプションはコードサイズとしています。

	ARM7 32bit	ARM7 Thumb	CM3 Thumb-2	AVR	H8/300H	PIC24	RL78	V850ES	SH-2A	RX600	IA-32
Compiler	GCC	GCC	GCC	GCC	CH38	C30	CC78K0R	CA850	SHC	RXC	VC6
_WORD_ACCESS	0	0	0	1	0	0	0	1	0	1	1
text (Full, R/W)	10675	7171	6617	13355	10940	11722	13262	8113	9048	6032	7952
text (Min, R/W)	6727	4631	4331	8569	7262	7720	9088	5287	5800	3948	5183
text (Full, R/O)	4731	3147	2889	6235	5170	5497	6482	3833	3972	2862	3719
text (Min, R/O)	3559	2485	2295	4575	4064	4240	5019	2993	3104	2214	2889
bss	V*4 + 2	V*4 + 2	V*4 + 2	V*2 + 2	V*4 + 2	V*2 + 2	V*2 + 2	V*4 + 2	V*4 + 2	V*4 + 2	V*4 + 2
Work area (_FS_TINY == 0)	V560 + F550	V560 + F550	V560 + F550	V560 + F544	V560 + F550	V560 + F544	V560 + F544	V560 + F544	V560 + F550	V560 + F550	V560 + F550
Work area (_FS_TINY == 1)	V560 + F36	V560 + F36	V560 + F36	V560 + F32	V560 + F36	V560 + F32	V560 + F32	V560 + F36	V560 + F36	V560 + F36	V560 + F36

FatFs R0.10a options:
_FS_READONLY     0 (R/W) or 1 (R/O)
_FS_MINIMIZE     0 (Full function) or 3 (Minimized function)
_USE_STRFUNC     0 (Disable string functions)
_USE_MKFS        0 (Disable f_mkfs function)
_USE_FORWARD     0 (Disable f_forward function)
_USE_FASTSEEK    0 (Disable fast seek feature)
_CODE_PAGE       932 (Japanese Shift_JIS)
_USE_LFN         0 (Disable LFN feature)
_MAX_SS          512 (Fixed sector size)
_FS_RPATH        0 (Disable relative path feature)
_FS_LABEL        0 (Disable volume label functions)
_VOLUMES         V (Number of logical drives to be used)
_MULTI_PARTITION 0 (Single partition per drive)
_FS_REENTRANT    0 (Disable thread safe)
_FS_LOCK         0 (Disable file lock control)

モジュールサイズの縮小

次の表は構成オプションの設定値によりどの機能が削除されるかを示します。

Function

_FS_MINIMIZE

_FS_READONLY

_USE_STRFUNC

_FS_RPATH

_FS_LABEL

_USE_MKFS

_USE_FORWARD

_MULTI_PARTITION

1/2

0/1

f_mount

f_open

f_close

f_read

f_write

f_sync

f_lseek

f_opendir

f_closedir

f_readdir

f_stat

f_getfree

f_truncate

f_unlink

f_mkdir

f_chmod

f_utime

f_rename

f_chdir

f_chdrive

f_getcwd

f_getlabel

f_setlabel

f_forward

f_mkfs

f_fdisk

f_putc

f_puts

f_printf

f_gets

長いファイル名

FatFsモジュールは、長いファイル名(LFN)をサポートします。ファイルに付けられた2つの異なる名前(短いファル名と長いファイル名)は、f_readdir()を除くファイル操作関数において透過です。デフォルト構成では、LFN機能はOFFになっています。LFN機能を有効にするには、_USE_LFNを1,2または3に設定し、option/unicode.cをプロジェクトに追加します。LFN機能は、加えてある程度のワークエリア(LFN操作バッファ)を必要とします。バッファ長は使用できるメモリに応じて_MAX_LFNオプションで構成されることができます。LFNの長さは最大255文字に達するので、LFN完全対応のためには_MAX_LFNは255に設定されるべきです。与えられたファイル名に対してバッファ長が不足した場合、ファイル関数はFR_INVALID_NAMEで失敗します。

ファイル関数に再入を行う条件の下でLFN機能を使用する場合は、_USE_LFNは2または3に設定されなければなりません。この場合、ファイル関数はワークエリアを動的に確保(スタックまたはヒープ)します。バッファサイズは、(_MAX_LFN + 1) * 2バイトになるので、スタック等のサイズはそれを考慮した十分なサイズでなければなりません。

LFN cfg on ARM7
コードページ	コードサイズ[bytes]
SBCS	+3721
932(Shift_JIS)	+62609
936(GBK)	+177797
949(Korean)	+139857
950(Big5)	+111497

LFN機能の上手な使い方は、それを使わないということです。実際、組み込み用途ではLFN機能がどうしても必要になるということはほとんど無いはずです。LFNを有効にすると、選択されたコードページに応じてモジュールサイズが増大します。右の表に各コードページにおけるLFNを有効にしたときのモジュールサイズの違いを示します。特に、CJK地域では数万の文字が使われていますが、不幸なことにそれは巨大なOEM－Unicode相互変換テーブルを要求し、モジュールサイズは劇的に増大します。その結果、それらのコードページにおいてLFNを有効にしたFatFsモジュールは、多くの8ビットマイコンにインプリメントすることができません。

LFN機能のハードルはそれだけではありません。マイクロソフト社はFATファイルシステムについていくつかの特許を保有しています。いずれもLFN機能の実装に関するもので、その利用に対して$0.25/unitのライセンス料を要求しています。このため、商用製品でLFN機能を利用するときは、最終仕向地によってはライセンスが必要になります。最近のFAT32ドライバの多くはLFN機能を含んでいるため、それらの使用に当たってライセンスが必要になりますが、FatFsではLFN機能を構成オプションで任意にON/OFFできるため、無効にしてライセンス問題を回避することもできます。

日本語ファイル名の大文字変換

CP932(Shift_JIS)でかつ非LFN構成のときは、拡張文字の小文字(2バイト英字・キリル文字・ギリシャ文字)に対して大文字変換を行わず、小文字のままSFNエントリに記録・検索されます(日本語MSDOS仕様)。このため、非LFN構成で全角小文字を含むファイルを作成すると、NT系Windowsでそのファイルを開けなくなります。LFN構成では大文字変換を行います(NT系Windows仕様)。

Unicode入出力への対応

FatFs API上におけるファイル名等の文字列データの入出力は、デフォルトではANSI/OEMコードで行われますが、これをUnicode(UTF-16)に切り替えることもできます(_LFN_UNICODEオプションで設定)。つまり、これはFatFsがLFN機能に完全対応していることを意味します。Unicodeのファイル名に関する詳細は、ファイル名を参照してください。

リエントランシー

互いに異なるボリュームに対するファイル操作はリエントラントで、常に同時平行に動作できます。同じボリュームに対してはデフォルトではリエントラントではありませんが、_FS_REENTRANTオプションでリエントラント(スレッドセーフ)にすることはできます。この場合、OS依存の同期オブジェクト操作関数ff_cre_syncobj(), ff_del_syncobj(), ff_req_grant(), ff_rel_grant()もまたプロジェクトに追加されなければなりません。サンプルコードと解説はoption/syncobj.cにあります。

この場合、あるタスクがボリュームを使用中に他のタスクからそのボリュームに対するファイル関数が呼び出されると、そのアクセスは先のタスクがファイル関数を抜けるまでブロックされます。もし、待ち時間が_TIMEOUTで指定された期間を越すと、その関数はFR_TIMEOUTでアボートします。いくつかのRTOSではタイムアウト機能はサポートされないかも知れません。

ひとつの例外がf_mount(), f_mkfs(), f_fdisk()にあります。これらの関数は同じボリューム(または関連する物理ドライブ)に対してリエントラントではありません。これらの関数を使用するときは、アプリケーションレベルで排他制御しなければなりません。

注: このセクションはFatFsモジュールそれ自体のリエントランシーについて説明しています。その下位のディスクI/Oモジュールのリエントランシーに関しては何の前提もありません。

多重ファイルアクセス

FatFsモジュールではデフォルトでは多重アクセス制御機能をサポートしていません。ファイルに対する多重アクセスは、そのアクセスモードによって制限されます。一つのファイルに対する多重オープンは、それらが全てリードモードのときに限って許可されます。書き込みモードを含む多重オープン、また開かれているファイルに対するリネームや削除を行ってはなりません。さもないと、そのボリュームのFAT構造が破壊される可能性があります。

_FS_LOCKに1以上の値(値は同時に管理できるファイル数)をセットすることで多重アクセス制御機能が有効になり、ファイル単位のアクセス制御を自動で行うこともできます。この場合、上記のルールを破ったオープン・リネーム・削除を試みると、その関数はFR_LOCKEDで失敗します。また、_FS_LOCKを越える数のファイルやサブディレクトリを同時にオープンしようとすると、FR_TOO_MANY_OPEN_FILESで失敗します。

効率的なファイルアクセス

小規模な組込システムでのファイルの読み書きにおける効率の良いアクセスのため、アプリケーションプログラマはFatFsモジュールの中でどのような処理が行われているか考慮すべきです。ストレージ上のデータはf_read()により次のシーケンスで転送されます。

図1. セクタミスアラインドリード (ショート)
fig.1

図2. セクタミスアラインドリード (ロング)
fig.2

図3. セクタアラインドリード
fig.3

ファイルI/Oバッファはセクタの一部のデータを読み書きするためのセクタバッファを意味します。セクタバッファは、それぞれのファイルオブジェクト内のプライベートセクタバッファまたはファイルシステムオブジェクト内の共有セクタバッファのどちらかです。バッファ構成オプションの_FS_TINYは、データ転送にどちらを使うかを決定します。タイニーバッファ(1)が選択されるとデータメモリの消費はそれぞれのファイルオブジェクトで_MAX_SSバイト減少されます。この場合、FatFsモジュールはファイルデータの転送とFAT/ディレクトリアクセスにファイルシステムオブジェクト内のセクタバッファだけを使用します。タイニーバッファの欠点は、セクタバッファにキャッシュされたFATデータがファイルデータの転送により失われ、クラスタ境界の毎にリロードされなければならないことです。でも、悪くない性能と少ないメモリ消費の視点から多くのアプリケーションに適するでしょう。

図1はセクタの一部のデータがファイルI/Oバッファを経由で転送されることを示します。図2に示される長いデータの転送では、転送データの中間の1セクタまたはそれ以上のセクタにまたがる転送データがアプリケーションバッファに直接転送されています。図3は転送データ全体がセクタ境界にアライメントされている場合を示しています。この場合、ファイルI/Oバッファは使用されません。直接転送においては最大の範囲のセクタがdisk_read()で一度に読み込まれますが、クラスタ境界を越えるマルチセクタ転送はそれが隣接であっても行われません。

このように、セクタにアライメントしたファイルの読み書きへの配慮はバッファ経由のデータ転送を避け、読み書き性能は改善されるでしょう。その効果に加え、タイニー構成でキャッシュされたFATデータがファイルデータの転送によりフラッシュされず、非タイニー構成と同じ性能を小さなメモリフットプリントで達成できます。

フラッシュメモリの特性への配慮

HDDなどのディスクメディアとは異なり、SDCやCFCなどのフラッシュメモリメディアの性能を引き出すには、その特性を意識した制御が必要になります。

マルチセクタ書き込み

図6. マルチ/シングルセクタライトの比較
fig.6

フラッシュメモリメディアの書き込み速度はシングルセクタ書き込みの時に最も低いものになり、一回のトランザクションで転送されるセクタ数が大きくなるほど書き込み速度は向上します。この効果はバス速度が高速になるほど顕著で、10倍以上の差が現れることも珍しくありません。テスト結果は、マルチセクタ書き込み(W:16K, 32 sectors)がシングルセクタ書き込み(W:100, 1 sector)よりどの程度速いかを明確に示しています。大容量メディアほどシングルセクタ書き込みが遅くなる点もまた重要です。書き込みトランザクションの回数はまた、メディアの寿命にも影響してきます。このため、アプリケーションはなるべく大きなブロック(クラスタサイズまたは2の累乗セクタ境界にアライメントした)で読み書きを行う必要があります。もちろん、アプリケーションからメディアに至る全てのレイヤがマルチセクタ転送に対応していないと意味がありません。残念ながら、既存のオープンソースのドライバの多くはマルチセクタ転送に未対応です。なお、FatFsモジュールおよびサンプルドライバはマルチセクタ転送に対応しています。

明示的なメモリ消去

通常のファイル消去では、記録されたデータに対して何らかの制御が行われるわけではなく、単にFAT上に未使用クラスタとして記録されているだけです。このため、ファイルが消去されたあともそれらは有効なメモリブロックとしてフラッシュメモリ上に残ります。そこで、ファイルを消去するとき、占有していたデータセクタを明示的に消去(つまり未使用ブロックにする)することにより、メディア内の空きブロックを増やすことができます。これにより、次にそのブロックに書き込むときの消去動作が無くなり、書き込み性能が向上する可能性があります。また、ウェアレベリングに使えるブロックが増え、メディアの耐久性も向上するかも知れません。この機能を有効にするには、構成オプションの_USE_TRIMに1を設定します。これはフラッシュメモリメディアの内部動作に期待した制御なので、効果があるとは限りません。また、ファイル消去の時間が延びることも考慮に入れるべきです。

クリチカルセクション

ストレージ上のFAT構造を操作している途中で、停電、不正なメディアの取り外し、回復不能なデータエラー等の障害が発生すると、処理が中途半端な状態で中断され、その結果としてFATボリュームの構造が破壊される可能性があります。次にFatFsモジュールにおけるクリチカルセクションと、その間の障害により起きうるエラーの状態を示します。

図4. 長いクリチカルセクション
fig.4

図5. 最小化したクリチカルセクション
fig.5

赤で示したセクションを実行中に障害が発生した場合、クロスリンクが発生して操作対象のファイルディレクトリが失われる可能性があります。黄色で示したセクションを実行中に障害が発生した場合、つぎのうちいずれかまたは複数の結果が生じる可能性があります。

書き換え中のファイルのデータが破壊される。
追記中のファイルがオープン前の状態に戻る。
新規に作成されたファイルが消える。
新規または上書きで作成されたファイルの長さがゼロになって残る。
ロストチェーンの発生によりボリュームの利用効率が悪化する。

いずれも書き込み中や操作の対象でないファイルには影響はありません。これらのクリチカルセクションは、ファイルを書き込みモードで開いている時間を最小限にするか、f_sync()を適宜使用することで図5のようにリスクを最小化することができます。

APIの拡張的使用例

FatFs APIの拡張的使用例です。有用なコードがあった場合は、随時追加していきます。。

FatFsのライセンスについて

ソースファイルのヘッダにライセンス条件が記述されているので、利用の際はそれに従うこと。英語を読めない方のために以下に日本語訳を示しておきます。

/*----------------------------------------------------------------------------/
/  FatFs - FAT file system module  R0.10b                   (C)ChaN, 2014
/-----------------------------------------------------------------------------/
/ FatFsモジュールは、小規模な組み込みシステム向けの汎用FATファイルシステム 
/ モジュールです。これはフリー ソフトウェアとして、教育・研究・開発のために
/ 以下のライセンス ポリシーの下で公開されています。
/
/  Copyright (C) 2014, ChaN, all right reserved.
/
/ * FatFsモジュールはフリー ソフトウェアであり、また無保証です。
/ * 用途に制限はありません。あなたの責任の下において、個人的・非営利的な
/   ものから商用製品の開発に及ぶ目的に使用・改変・再配布することができます。
/ * ソース コードを再配布するときは、上記の著作権表示を保持しなければなりません。
/
/-----------------------------------------------------------------------------/

要するにFatFsはタダで自由に使えるということです。ソースコードを再配布するときは、このブロックをそのまま保持しておくこと。このようにFatFsはBSDライクなライセンスとしていますが、一つ大きな違いがあります。特に組み込み用途での利用価値を高めるため、バイナリ形式(ソースコードを含まない形式全て)での再配布については、条件は設けていません。その場合は、FatFsおよびそのライセンス文書についてはドキュメントに明記してもしなくてもかまいません。これは、一条項BSDライセンスと等価ということです。もちろんGNU GPLプロジェクトとも共存可能です。何らかの変更を加えて再配布する際は、矛盾しない他のライセンス(GNU GPLや修正BSDライセンスなど)に変更することも可能です。

FatFsモジュール アプリケーション ノート