SDカード内のファイル検索について

yama_shinさん
テキストファイル数が数万単位は遅くなるんじゃないですか、RL78G14でもPC並みには無理じゃないかと思います、たぶんバッファRAMを大きくしても、目立つほど早くはならないと思います。

ひとつのフォルダに格納するファイルの数を制限すべきですね。

yama_shinさん

はじめまして、Hosです。
SDカードということは、FATを使用していると思います。
私が知っているのはFAT32ですが(組み込みでexFATは使ったことないので違っていたらすいません)、フォルダの中身を検索する際に1つのフォルダの中の同一階層に多くのファイル・フォルダがあると、ファイルシステムの構造的に検索に非常に時間がかかる仕組みとなっています。
これは、1つのディレクトリの中にディレクトリエントリと呼ばれるデータがたくさんできるためです。

インデックスファイルからパスを作成してアクセスしていても、ファイルシステムの中身としては該当のファイルにアクセスするために検索処理が走りますのでこれがボトルネックになっていると思います。
改善策としては、フォルダの中にサブフォルダを作り、その中にログファイルを作るよう構造化していくと検索量が減ってアクセス速度が改善する可能性があります。

IKUZOさん　yama_shinです。お世話になります。
ご意見ありがとうございます。1フォルダにデータ格納していましたのでアクセスが遅くなっているかもしれません。PCで開く場合も結構遅いので、保存方法を変えて試してみます。

fujita nozomuさん　yama_shinです。お世話になります。
月単位のフォルダで区切れば、最大ファイル数も制限できると思いますので試してみたいと思います。

Hosさん　yama_shinです。はじめまして、お世話になります。
詳細なご意見ありがとうございます。

FAT32ですね。
>フォルダの中にサブフォルダを作り、その中にログファイルを作るよう構造化していくと検索量が減ってアクセス速度が改善する可能性があります。
こちらの方法を確認して試してみます。＊ログファイルの生成は調べてみます。

イメージとしては、以下のような構造でindexには月単位のインデックスからサーチするのかな？と思っています。
満タンになった時は月フォルダごと消せばと考えもしましたが、消すのにも結構時間がかかる気もしています。
＊1ヶ月で最大2-3万ファイル程度です。

|--Index.txt
|--Dir_Data
|--Dir_201901
| |--data001.dat
| |--data002.dat
|--Dir_201902
| |--data003.dat
| |--data004.dat

＞満タンになった時は月フォルダごと消せばと考えもしましたが、消すのにも結構時間がかかる気もしています。
恐らくyama_shinさんご懸念の通りの事象となるとおもいます。

一例ですが、Indexをサイクリックにしてしまって、ログファイルを新規作成する際には最古の1ファイルのみ消してからファイル作成して書き込むというのはいかがでしょうか。
この場合は大量削除は発生せず、1ファイル削除して1ファイル書き込むというのが最遅動作になるかと思います。
16万ファイルぐらいなら、1フォルダあたり400ファイルにすると、400フォルダで16万ファイルになるのできりがいいでしょうか。(1フォルダ400でも遅いなら、もう1段追加する)

Index値は0,1,2,…,159999,0,1,2,…というように動かした場合、
生成するログファイル名は以下のように制御します。
Dir_000/data000000.dat
Dir_000/data000001.dat
Dir_000/data000002.dat
　　：
　　：
Dir_399/data159999.dat
Dir_000/data000000.dat　★同名のファイルを1ファイルのみ削除してから新規作成
Dir_000/data000001.dat　★同名のファイルを1ファイルのみ削除してから新規作成
Dir_000/data000002.dat　★同名のファイルを1ファイルのみ削除してから新規作成

ただし、この場合はuSDのサイズぎりぎりまで書き込むことはできません。
1ファイルあたり72Kbyteとのことですので、Indexの上限値でどの程度のサイズをログに割り当てるのか決める必要があります。

yama_shinさん
IKUZOです。ひとつアイデアが、
ログファイルを512Byte固定長として扱えるならばDOSを使用しないで、
セクタライトとセクタリードのみを使用して最適化することも可能とは思います
インデックスファイルは使用せず計算式でデーターの位置を割り出します
RTCの値を64ビットtimeに変換して、例えば
セクター番号=(time/block)-offsetのような
blockはログファイル長、offsetは現在の日時になります
それでセクターライトします、SDカードのサイズで循環するので
一番古いデーターが上書きされますから一杯になる心配がありません
リードするときも同じ計算式でoffsetは読み出したい日時で
セクターリードします、
これだとセクター0からSDカードを有効利用できますし
考えうる最も利用効率の高い、アクセス速度の速い方法だと思います。
相当の作りこみが必要だと思いますが、

Hosさん　おはようございます。yama_shinです。
ご提案ありがとうございます。少し試してみました。

フォルダ内のファイル数の上限を指定してもFat自体が領域を面で捉えている性質？なのかもしれませんが、結局フォルダ数＊ファイル数でリードに時間がかかり、トータルの時間はそれほど改善しない傾向が見られました。まだトライ中ですので、改善がみられましたらご報告いたします。誠にありがとうございます。

IKUZOさん　おはようございます。yama_shinです。
ご提案ありがとうございます。

頂いた情報と似ているのですが、調べていく中で検索する際は古いファイルから順に追っていくような動作が見られました。更新したインデックスが毎回一番新しくなるので、ファイルが多くなると遅くなるのでは？と思っています。。。逆に読めたら速そうなのですが、そこまでまだ手がでません。
RTCを利用しての循環動作は良さそうですね。少しずつ検討してみます。ありがとうございます。

yama_shinさんはじめまして。
フォルダを分ける場合はあらかじめ階層を作って置くのはどうでしょうか。
年->月->日→データファイルといった具合です。
セクタ内には16個のファイル情報しか入りませんので、16ファイル（フォルダ）を検索するたびに、
FATテーブルを参照する余分な処理が含まれることになりますので、
１フォルダ内のファイル・フォルダ数を16個以内にすると良いかもしれません。
あらかじめ作成する意味は、おそらく、fat32だと思いますので、
ルートディレクトリの領域は作られず、
ディスク内に点在してしまうことが考えられます。
断片化するとアクセスに時間がかかりますので、フォルダ情報はあらかじめ、
カードの初めの方に作成してしまうという考えです。
自分場合は、あらかじめ数MBのファイルを作成しておき、固定長でその中を書き換える方法をとっています。
先頭から1kB目は1日、2kB目は2日・・・といった具合です。
シークの動作が必要ですが、連続ファイルならFATテーブルを読み飛ばせばそれなりの速度が出ると思います。
（ドライバの作りによるとは思いますが、）
無論、ファイルの中身を上書きしてしまうので、削除の必要がなくなります。
IKUZOさんの、固定長でセクタを使用する方法を、既存のFATモジュールで使用できます。