Renesas Rulz - Japan
Search Japan.RenesasRulz.com
User
Join or sign in
Site
Search Japan.RenesasRulz.com
User
Renesas
Rulz
FAQ
パートナー
半導体セミナ
eラーニング
ヘルプ
More
Cancel
かふぇルネ
がじぇるね
English Community
More
Cancel
かふぇルネ
101: RL78 - Forum
SDカード内のファイル検索について
RA
RE
RL78
RX
RZ
開発ツール
チョコさんのRL教室
サンプルプログラム等
More
Cancel
New
Replies
12 replies
Subscribers
425 subscribers
Views
8175 views
Users
0 members are here
FATファイル管理
SDカード
exFat
M3S-TFAT-TINY
RL78
高速化
バッファ
ファイル検索
クラスタリンク情報
Open/Closeサイクル
ディレクトリ エントリ構造体
アロケーションユニットサイズ
G14
Options
Share
More
Cancel
SDカード内のファイル検索について
yama_shin
over 1 year ago
はじめまして、yama_shinと申します。
RL78G14を使用して、SDカードのリードライトをしておりますが、テキストファイル数が数万単位になると
非常に読み込みが遅くなり対処に困っております。早く読みだす方法はございますでしょうか。
*当方はSDカードの実装初めてです。宜しくお願い致します。
<用途>
・データロガー
<やっている実験>
・約16万ファイル(1ファイルは72Kbyte)、16GBのuSDを使用し満タンになると最も古いファイルを上書きする。
・インデックスファイルを使用して検索するようにしています。
・シリアルクロックは4MHzです。
<遅くなっている原因と思われる現象>
・特定のファイルを探す、削除する動作があると数秒単位で遅くなる。
・16万ファイルでは、特定ファイルを検索するファンクション動作(ステータス、ファイルオープン等)1つに6秒程度かかる。
IKUZO
over 1 year ago
yama_shinさん
テキストファイル数が数万単位は遅くなるんじゃないですか、RL78G14でもPC並みには無理じゃないかと思います、たぶんバッファRAMを大きくしても、目立つほど早くはならないと思います。
Cancel
Up
0
Down
Reply
Cancel
fujita nozomu
over 1 year ago
ひとつのフォルダに格納するファイルの数を制限すべきですね。
Cancel
Up
0
Down
Reply
Cancel
Hos
over 1 year ago
in reply to
IKUZO
yama_shinさん
はじめまして、Hosです。
SDカードということは、FATを使用していると思います。
私が知っているのはFAT32ですが(組み込みでexFATは使ったことないので違っていたらすいません)、フォルダの中身を検索する際に1つのフォルダの中の同一階層に多くのファイル・フォルダがあると、ファイルシステムの構造的に検索に非常に時間がかかる仕組みとなっています。
これは、1つのディレクトリの中にディレクトリエントリと呼ばれるデータがたくさんできるためです。
インデックスファイルからパスを作成してアクセスしていても、ファイルシステムの中身としては該当のファイルにアクセスするために検索処理が走りますのでこれがボトルネックになっていると思います。
改善策としては、フォルダの中にサブフォルダを作り、その中にログファイルを作るよう構造化していくと検索量が減ってアクセス速度が改善する可能性があります。
Cancel
Up
0
Down
Reply
Cancel
yama_shin
over 1 year ago
in reply to
IKUZO
IKUZOさん yama_shinです。お世話になります。
ご意見ありがとうございます。1フォルダにデータ格納していましたのでアクセスが遅くなっているかもしれません。PCで開く場合も結構遅いので、保存方法を変えて試してみます。
Cancel
Up
0
Down
Reply
Cancel
yama_shin
over 1 year ago
in reply to
fujita nozomu
fujita nozomuさん yama_shinです。お世話になります。
月単位のフォルダで区切れば、最大ファイル数も制限できると思いますので試してみたいと思います。
Cancel
Up
0
Down
Reply
Cancel
yama_shin
over 1 year ago
in reply to
Hos
Hosさん yama_shinです。はじめまして、お世話になります。
詳細なご意見ありがとうございます。
FAT32ですね。
>フォルダの中にサブフォルダを作り、その中にログファイルを作るよう構造化していくと検索量が減ってアクセス速度が改善する可能性があります。
こちらの方法を確認して試してみます。*ログファイルの生成は調べてみます。
イメージとしては、以下のような構造でindexには月単位のインデックスからサーチするのかな?と思っています。
満タンになった時は月フォルダごと消せばと考えもしましたが、消すのにも結構時間がかかる気もしています。
*1ヶ月で最大2-3万ファイル程度です。
|--Index.txt
|--Dir_Data
|--Dir_201901
| |--data001.dat
| |--data002.dat
|--Dir_201902
| |--data003.dat
| |--data004.dat
Cancel
Up
0
Down
Reply
Cancel
Hos
over 1 year ago
in reply to
yama_shin
>満タンになった時は月フォルダごと消せばと考えもしましたが、消すのにも結構時間がかかる気もしています。
恐らく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の上限値でどの程度のサイズをログに割り当てるのか決める必要があります。
Cancel
Up
0
Down
Reply
Cancel
IKUZO
over 1 year ago
in reply to
yama_shin
yama_shinさん
IKUZOです。ひとつアイデアが、
ログファイルを512Byte固定長として扱えるならばDOSを使用しないで、
セクタライトとセクタリードのみを使用して最適化することも可能とは思います
インデックスファイルは使用せず計算式でデーターの位置を割り出します
RTCの値を64ビットtimeに変換して、例えば
セクター番号=(time/block)-offsetのような
blockはログファイル長、offsetは現在の日時になります
それでセクターライトします、SDカードのサイズで循環するので
一番古いデーターが上書きされますから一杯になる心配がありません
リードするときも同じ計算式でoffsetは読み出したい日時で
セクターリードします、
これだとセクター0からSDカードを有効利用できますし
考えうる最も利用効率の高い、アクセス速度の速い方法だと思います。
相当の作りこみが必要だと思いますが、
Cancel
Up
0
Down
Reply
Cancel
yama_shin
over 1 year ago
in reply to
Hos
Hosさん おはようございます。yama_shinです。
ご提案ありがとうございます。少し試してみました。
フォルダ内のファイル数の上限を指定してもFat自体が領域を面で捉えている性質?なのかもしれませんが、結局フォルダ数*ファイル数でリードに時間がかかり、トータルの時間はそれほど改善しない傾向が見られました。まだトライ中ですので、改善がみられましたらご報告いたします。誠にありがとうございます。
Cancel
Up
0
Down
Reply
Cancel
yama_shin
over 1 year ago
in reply to
IKUZO
IKUZOさん おはようございます。yama_shinです。
ご提案ありがとうございます。
頂いた情報と似ているのですが、調べていく中で検索する際は古いファイルから順に追っていくような動作が見られました。更新したインデックスが毎回一番新しくなるので、ファイルが多くなると遅くなるのでは?と思っています。。。逆に読めたら速そうなのですが、そこまでまだ手がでません。
RTCを利用しての循環動作は良さそうですね。少しずつ検討してみます。ありがとうございます。
Cancel
Up
0
Down
Reply
Cancel
HiRoSan
over 1 year ago
yama_shinさんはじめまして。
フォルダを分ける場合はあらかじめ階層を作って置くのはどうでしょうか。
年->月->日→データファイルといった具合です。
セクタ内には16個のファイル情報しか入りませんので、16ファイル(フォルダ)を検索するたびに、
FATテーブルを参照する余分な処理が含まれることになりますので、
1フォルダ内のファイル・フォルダ数を16個以内にすると良いかもしれません。
あらかじめ作成する意味は、おそらく、fat32だと思いますので、
ルートディレクトリの領域は作られず、
ディスク内に点在してしまうことが考えられます。
断片化するとアクセスに時間がかかりますので、フォルダ情報はあらかじめ、
カードの初めの方に作成してしまうという考えです。
自分場合は、あらかじめ数MBのファイルを作成しておき、固定長でその中を書き換える方法をとっています。
先頭から1kB目は1日、2kB目は2日・・・といった具合です。
シークの動作が必要ですが、連続ファイルならFATテーブルを読み飛ばせばそれなりの速度が出ると思います。
(ドライバの作りによるとは思いますが、)
無論、ファイルの中身を上書きしてしまうので、削除の必要がなくなります。
IKUZOさんの、固定長でセクタを使用する方法を、既存のFATモジュールで使用できます。
Cancel
Up
0
Down
Reply
Cancel
yama_shin
over 1 year ago
in reply to
HiRoSan
HiRoSanさん 初めまして。yama_shinです。
ファイル長の固定とう方法ですね。最大は72KB程度としており起動中のは、データを溜めていくので、短いフラグが合った場合は、冗長な領域ができてしまう事を懸念しています。ただ、ファイルシステムの性質上ご提案いただいている方法になりそうな感じです。(ドライバ対応がどこまでできるのか。。。ですね)
ありがとうございます。取り急ぎお礼まで。
Cancel
Up
0
Down
Reply
Cancel