ファイルシステムの選択（FAT３２かNTFSか）について
新井
WindowsXP Embedded FP2007にて開発を行っているのですが、
採用するファイルシステムについて、候補としてはFAT３２とNTFSを
考えております。
Embeddedのシステムを採用している各社さんは、多数がFAT３２を
採用しているように見受けられるのですが、パフォーマンスや
信頼性の点では、NTFSのほうが優れているという情報が得られました。
一長一短はあると思うのですが、NTFSを使いファイルが読み出しできない
ことがないようにしたいと考えており、NTFSのジャーナリングという点について
調査したいと考えています。
質問
NTFSはジャーナリングファイルシステム
（http://ja.wikipedia.org/wiki/%E3%82%B8%E3%83%A3%E3%83%BC%E3%83%8A%E3%83%AB%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0）
を採用しているとのことですが、XPEでNTFSを採用した場合にジャーナリングファイルシステムは有効かどうかをご回答いただきたいのです。
scandiskのコンポーネントを選択しているので、問題があれば
起動時に修復が開始されるようです。（２０００、XP等の場合）
検証方法としては、fsutilでドライブをダーティにセットして
確認ことを考えています。
ただ、XPEにはfsutilは標準で選べるコンポーネントとして存在していないようです。さくっと確認できれば良いのですが別の問題のため対応できていない状態なのです。
そもそもCFでなぜNTFSを選択したいのか？
->基本的はシステムとアプリケーションのドライブは書き換えを禁止して
ログデータなどはFBWFで書き込み許可、またはEWFを指定しない
２つめのパテーションにファイルを保存するように考えております。
装置の運用は電源をもとから遮断しても重大な故障が発生しないことが
求められ、電源遮断によりファイルシステムが破損することを回避する
必要があります。
このため、通常はファイルの書き込みには外部にNVRAMや、ダブル
バッファリングで記録情報が失われないようにしますが、FATなどの場合は、
ファイル書き込み中に電源が遮断した場合に最悪ファイルシステムが
破損してしまいドライブの読み出しができないようなケースがあるのではと
考えております。
これに対してNTFSはジャーナリングファイルシステムを採用しているとの
ことで、保存したファイルの完全性は保障されないが、保存前の情報に
戻るくらいで、重大な故障に発展せず、自己修復するようなしくみを
もっていると認識しているため、NTFSを使いたいのです。
ターゲットシステム構成
CPU：GeodeLX ７００
RAM：１GB
HDD：CF（リムーバブル、または固定ディスクタイプ）１GB～８GB
パテーションは１パテーションまたは２パテーション
フォーマットはFAT３２かNTFS（できればNTFS）
遅延書き込みは無効
Microdrive上でFBAを実行後、ターゲット用CFに書き込み
周辺機器：タッチパネル、USBストレージ、USBキーボード等
ライトフィルタ：FBWFで１パテーションまたはEWFのRAMモードで２パテーション（オーバーレイ含めて３パテーション？）
CFにリムーバブルと固定ディスクの両方がある理由
->ターゲットの最終的な仕様は固定ディスクとして認識されるものを使用する
のですが評価やシステム設計を行うにあたり、比較的高価でシステムの
要求するCFの容量などが不明のため、検証作業のとっかかかりは市販の
安価なCFを使いた経緯があるのです。
ただこの場合は、XPにおいてリムーバブルと認識されるメディアは
複数パテーションの作成を許可されていないため、2パテーション構成の
検証ができません。このため、Hitachi MicroDriveの固定ディスク認識の
デバイスドライバを用いて仮に固定ディスク化しています。
なぜかというと、ipod nanoなどのシリコンオーディオの増加で
フラッシュメモリの需要増があり、ICの切替時期にかかっているため、
入手のタイミングを見極めている状態なのです。
デメリットとしては、開発機とターゲットにこのドライバを入れないと
２つめのパテーションが表示されない問題が残ります。
宮ヶ野 (Miyagano)
FAT３２にするかNTFSか？とのことですが
信頼性から判断すると、NTFSをおすすめします。
信頼性という意味での試験としては
fsutilにてダーティビットを立てるよりは
ファイル作成、書き込みテスト中に
システムリセットなどが適切かもしれません。
NTFSにおける課題は、CFなどの小容量デバイスでは
クラスタサイズが小さすぎるようにおもっています。
この点は、バックグラウンドデフラグが有効なのでしょうが
XPeでEWFを使用した場合、このサービスは停止させるので
少々悩ましいところがあります。
検証したことはないのですが、書き込むファイル
によっては２K、または４Kのクラスタサイズにてパーティションを
作成したほうがいいのかもしれません。
ファイルシステムの検討とは関係ありませんが、
ご使用のマザーボードにIDEコネクタがあり、
CFをFixedにて使用される予定でしたら
HDDにて開発し、最終的にCFに移すことで
問題ないとおもいます。
実運用試験ではなく、OSのビルドという観点からいえば
無理にCFで作業することはないとおもいます。
ご参考まで
--
宮ヶ野
"新井" からの元のメッセージ:
新井
返信ありがとうございます。
アドバイスをいただきありがとうございます。
ファイルシステムはNTFSとする方向で検討したいと思います。
いくつか検証したなかで、fsutilによるダーティビットによる
強制的なチェックディスクが起動時に実行されるものと
考えていたのですが、XPとXPeは異なっているようで、
結果的にfustilによるダーティビットでチェックディスクは
実行されませんでした。
ジャーナルによるファイル保護については、
ライトフィルタをかけていないドライブでファイル書き込み中に
リセットした場合にファイルがどのように損傷するか、
ジャーナルによって保護されるレベルについて引き続き調査します。
（ファイルを連続して書き換えを行うテストプログラムを現在製作中です。）
CFのクラスタサイズが小さい点について
私の基本的な知識がなく誤解しているかもしれないので確認したいのですが、
クラスタサイズが小さいと、フラグメントが発生しやすいので
できればデフラグしてあげたほうが、良いということでしょうか。
"宮ヶ野 (Miyagano)" からの元のメッセージ:
宮ヶ野 (Miyagano)
> 考えていたのですが、XPとXPeは異なっているようで、
> 結果的にfustilによるダーティビットでチェックディスクは
> 実行されませんでした。
起動時の自動チェックディスクを実行させようとした場合、
もうひとつ設定が必要となります。
下記のchkntfs.exeをOSに組み込み、コマンドにより設定を
行ってみてください。
(1)起動時にチェックディスクを自動的に実行するようにします。
chkntfs /d
(2) ライトフィルタ対象のドライブは、対象から解除しておきます
chentfs /x c:
> CFのクラスタサイズが小さい点について
> 私の基本的な知識がなく誤解しているかもしれないので確認したいのですが、
> クラスタサイズが小さいと、フラグメントが発生しやすいので
> できればデフラグしてあげたほうが、良いということでしょうか。
できれば、デフラグを実行し、フラグメントを解消させることが良いとは
おもいますが、XPeシステムにおいて、デフラグをどのタイミングにて実行させるか？
が課題となります。
バックグランドデフラグをボリューム毎に設定でき、
フラッシュなどのメディアに対応した、書き込みが少ない
バックグランドデフラグがあればいいのですが・・・
新井さんのシステム（アプリケーション）が作成するファイルのサイズ、
書き込みや更新の頻度から検討して、クラスタサイズを大きくする
もしくは、ファイル書き込みにおいては、あらかじめ設定したサイズにて
ファイルを作成し、ファイルサイズ増加による断片化を防ぐ。
このことが現実解になるとおもいます。
WindowsXP Professionalリソースキット(上)P.590からの引用になりますが、
「クラスタサイズと作成するファイルのサイズによりクラスタサイズを検討した方が
良いとのことで、作成するファイルサイズが、作成後にサイズが増加する。または
作成するファイルのサイズがクラスタサイズ以上である場合には
断片化が発生進む。
そのような場合、クラスタサイズを大きくすことにより断片化を抑えることができる。」
とのことです。
ごさんこうください。
--
宮ヶ野
"新井" からの元のメッセージ:
新井
教えていただいた方法で、ダーティビットをセットすると、
XPe起動時に強制的にCHKDSKが起動しました。
ありがとうございました。
クラスタサイズについても見直す必要があるか確認したいと思います。
"宮ヶ野 (Miyagano)" からの元のメッセージ: