(57)【特許請求の範囲】
【請求項１】
電子装置によって少なくとも部分的に実装される方法であって、
前記電子装置のアプリケーションと関連づけられている書込み要求を受信することと、
メモリに前記書込み要求と関連したデータをバッファすることと、
バッファしたデータをトランザクションポリシーに従ってフラッシングの用意ができている区分に編成することであり、前記トランザクションポリシーがアプリケーションのアクセス特性に少なくとも部分的に基づいていることと、
フラッシングポリシーに従って区分に編成された前記バッファしたデータを前記メモリからフラッシュして、前記バッファしたデータをストレージに記憶することであり、前記フラッシングポリシーが、前記電子装置とのユーザ対話の状態、および前記電子装置の状態の１つまたは複数に少なくとも部分的に基づいていることと、
アプリケーションの前記アクセス特性がアプリケーションのデータ読み書きアクセスパターンを含み、かつバッファしたデータを区分に編成することが、
前記書込み要求と関連したアプリケーションの前記データ読み書きアクセスパターンに従って、閉じた区分に対するエネルギー向上度が所定の閾値より高いように、区分境界を決定することを含む、方法。
【請求項２】
フラッシングの用意ができている区分をフラッシュすることが、
前記電子装置のアプリケーションとのまたは前記電子装置とのユーザ入力対話に少なくとも部分的に基づいてフラッシングタイミングを決定することを含む、請求項１に記載の方法。
【請求項３】
フラッシングの用意ができている区分をフラッシュすることが、
区分の属性に少なくとも部分的に基づいてフラッシングの用意ができている区分をスケジュールすることをさらに含む、請求項２に記載の方法。
【請求項４】
フラッシングタイミングを決定することが、
前記電子装置のアプリケーションとのまたは前記電子装置とのユーザ入力対話を監視することと、
前記ユーザ入力対話の活動度が所定の閾値より低ければフラッシングを行うと決めることと、
ユーザ対話の履歴に基づいて前記フラッシングのための間隔を予測することとを含む、請求項２に記載の方法。
【請求項５】
区分の前記属性が、
区分の状態、
区分の親和性、
区分の長さ、および、
区分の年齢の１つまたは複数を含む、請求項３に記載の方法。
【請求項６】
メモリに前記書込み要求と関連したデータをバッファすることが、
受信した書込み要求に応じてアプリケーションと関連したジャーナルを維持することであり、前記ジャーナルにおけるログエントリが書込み要求に従って前記メモリのキャッシュユニットを参照することと、
参照されるキャッシュユニットからジャーナル内のログエントリへの逆マッピングを維持することとを含み、
バッファしたデータを区分に編成することが、
バッファしたデータの異なるバージョンを保持するための前記トランザクションポリシーに従って前記ジャーナルにおけるログエントリをトランザクションにグループ分けすることを含む、請求項１に記載の方法。
【請求項７】
メモリに前記書込み要求と関連したデータをバッファすることが、
受信した書込み要求と関連した目標キャッシュユニットが前記ジャーナル内のログエントリによって参照されているかどうかを、前記逆マッピングに基づいて確認することと、
前記目標キャッシュユニットが前記ジャーナルにおけるいずれのログエントリによっても参照されないことに応じて、前記ジャーナルに新しいログエントリを追加することと、
前記目標キャッシュユニットが前記ジャーナルにおける閉じたトランザクションにおけるログエントリによって参照されることに応じて、前記ジャーナルに新しいログエントリであり、前記書込み要求に従って前記目標キャッシュユニットの変更コピーと関連づけられる新しいログエントリを追加することと、
前記目標キャッシュユニットが開いたトランザクションにおけるログエントリによって参照されることに応じて、前記書込み要求に従って前記目標キャッシュユニットに上書きすることとをさらに含む、請求項６に記載の方法。
【請求項８】
フラッシングの用意ができている前記区分をフラッシュすることが、
前記フラッシングポリシーに従って永続ストレージに前記区分を記憶することを含む、請求項１に記載の方法。
【請求項９】
電子装置のためのファイルシステムにおけるフラッシングを制御するためのシステムであって、
メモリにおける書込み要求と関連したデータのバッファリングを管理するように構成され、前記書込み要求が前記電子装置のアプリケーションと関連づけられているバッファマネージャと、
バッファしたデータを前記メモリからフラッシュして前記バッファしたデータをストレージに記憶するように構成されるフラッシャと、
トランザクションポリシーおよびフラッシングポリシーを提供するように構成され、前記トランザクションポリシーがアプリケーションのアクセス特性に少なくとも部分的に基づいており、かつ前記フラッシングポリシーが前記電子装置とのユーザ対話または前記電子装置の状態の１つに少なくとも部分的に基づいているポリシーエンジンとを備え、
前記バッファマネージャが、前記トランザクションポリシーに従って前記メモリにおけるバッファしたデータをフラッシングの用意ができている区分に編成するようにさらに構成され、かつ、
前記フラッシャが、前記フラッシングポリシーに従って区分に編成された前記バッファしたデータを前記メモリからフラッシュするようにさらに構成され、
アプリケーションの前記アクセス特性がアプリケーションのデータ読み書きアクセスパターンであり、かつ前記バッファマネージャが、
前記書込み要求と関連したアプリケーションの前記データ読み書きアクセスパターンに従って、閉じた区分に対するエネルギー向上度が所定の閾値より高いように、区分境界を決定することによって、バッファしたデータを区分に編成するように構成される、システム。
【請求項１０】
前記フラッシャが、
前記電子装置のアプリケーションとのまたは前記電子装置とのユーザ入力対話に少なくとも部分的に基づいてフラッシングタイミングを決定することによって、フラッシングの用意ができている区分をフラッシュするように構成される、請求項９に記載のシステム。
【請求項１１】
前記フラッシャが、
区分の属性に少なくとも部分的に基づいてフラッシングの用意ができている区分をスケジュールすることによって、フラッシングの用意ができている区分をフラッシュするようさらに構成される、請求項１０に記載のシステム。
【請求項１２】
前記フラッシャが、
前記電子装置のアプリケーションとのまたは前記電子装置とのユーザ入力対話を監視し、
前記ユーザ入力対話の活動度が所定の閾値より低ければフラッシングを行うと決め、
ユーザ対話の履歴に基づいて前記フラッシングのための間隔を予測することによって、フラッシングタイミングを決定するように構成される、請求項１０に記載のシステム。
【請求項１３】
区分の前記属性が、
区分の状態、
区分の親和性、
区分の長さ、および、
区分の年齢の１つまたは複数を含む、請求項１１に記載のシステム。
【請求項１４】
前記バッファマネージャが、
受信した書込み要求に応じてアプリケーションと関連したジャーナルを維持するように構成され、前記ジャーナルにおけるログエントリが書込み要求に従って前記メモリのキャッシュユニットを参照するジャーナルコンポーネントと、
参照されるキャッシュユニットからジャーナル内のログエントリへの逆マッピングを維持するように構成される逆マッピングコンポーネントとを備え、
前記バッファマネージャが、バッファしたデータの異なるバージョンを保持するための前記トランザクションポリシーに従って前記ジャーナルにおけるログエントリをトランザクションにグループ分けすることによって、バッファしたデータを区分に編成するように構成される、請求項９に記載のシステム。
【請求項１５】
前記バッファマネージャが、
受信した書込み要求と関連した目標キャッシュユニットが前記ジャーナル内のログエントリによって参照されているかどうかを、前記逆マッピングに基づいて確認し、
前記目標キャッシュユニットが前記ジャーナルにおけるいずれのログエントリによっても参照されないことに応じて、前記ジャーナルに新しいログエントリを追加し、
前記目標キャッシュユニットが前記ジャーナルにおける閉じたトランザクションにおけるログエントリによって参照されることに応じて、前記ジャーナルに新しいログエントリであり、前記書込み要求に従って前記目標キャッシュユニットの変更コピーと関連づけられる新しいログエントリを追加し、
前記目標キャッシュユニットが開いたトランザクションにおけるログエントリによって参照されることに応じて、前記書込み要求に従って前記目標キャッシュユニットに上書きすることによって、データのバッファリングを管理するように構成される、請求項１４に記載のシステム。
【請求項１６】
前記フラッシャが、前記メモリにおける前記バッファしたデータを永続ストレージに記憶するように構成される、請求項９に記載のシステム。
【請求項１７】
実行されたとき電子装置においてアクションを行うコンピュータ実行可能命令を有するコンピュータ記憶媒体であって、前記アクションが、
前記電子装置のアプリケーションと関連づけられている書込み要求を受信することと、
メモリに前記書込み要求と関連したデータをバッファすることと、
アプリケーションのアクセス特性に少なくとも部分的に基づいて書込み要求をグループ分けすることによって前記バッファしたデータの異なるバージョンを維持することと、
前記電子装置とのユーザ対話の状態、および前記電子装置の状態の１つまたは複数に少なくとも部分的に基づいて前記バッファしたデータの前記異なるバージョンを前記メモリからフラッシュして前記バッファしたデータの前記異なるバージョンをストレージに記憶することと、
アプリケーションの前記アクセス特性がアプリケーションのデータ読み書きアクセスパターンであり、かつバッファしたデータを区分に分割することが、
前記書込み要求と関連したアプリケーションの前記データ読み書きアクセスパターンに従って、閉じた区分に対するエネルギー向上度が所定の閾値より高いように、区分境界を決定することを含む、コンピュータ記憶媒体。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  コンピューティングシステムでは、データがどのように記憶および検索されるかを制御するためにファイルシステムが使用される。ファイルシステムは記憶媒体におけるユーザデータを管理する。多くの異なる種類のファイルシステム、たとえばディスクファイルシステム、ネットワークファイルシステムおよび特殊目的ファイルシステムがある。各々は異なる構造および論理、速度、柔軟性、セキュリティ、サイズなどの性質を有してよい。ファイルシステムは、たとえば空間管理、保全性を維持することを含む様々な態様を伴う。
【０００２】
[0002]  大抵のファイルシステムはパーソナルコンピュータ（PC）−クラスシステムのために設計される。一般に、ＰＣ−クラスシステムに対する２つの主要なファイルシステム要件、信頼性および読み書きスループットがある。信頼性はデータを保証された整合性および耐久性で安全に保つ。信頼性は特に予期せぬシステムクラッシュ（たとえば、電力故障）の場合にはデータ損失に関係する。読み書きスループットはユーザアプリケーションの入出力（I/O）応答性に関係する。
【発明の概要】
【０００３】
[0003]  しかしながら、スマートフォン、タブレットコンピュータ、携帯情報端末（PDA）などといったポータブルまたはモバイル装置、およびいくつかの小型固定装置を含むがこれらに限定されない、非ＰＣ装置の現在のユーザは、データストレージおよび基礎をなす従来のファイルシステムによって引き起こされるアプリケーションの非応答性および高エネルギー消耗を経験する。そのような非ＰＣ装置は、いくつかの根本的に異なる制限および使用シナリオのために、ファイルシステムに著しく異なる課題をもたらす。１つの態様では、これらの装置は通常バッテリー駆動されるために限られたエネルギーを有し、したがってエネルギー流出はできるだけ低いべきである。別の態様では、高応答アプリケーション対話のユーザ体験が、モバイルエコシステムにおけるアプリケーションの成功を大いに推進する。したがって、そのような装置に適切なファイルシステムがエネルギー効率良くかつ高応答であることが望ましいだろう。
【課題を解決するための手段】
【０００４】
[0004]  本明細書に記載される主題の実施形態は一般に、電子装置のためのストレージに適応的に記憶する、書き込む、またはフラッシュする能力を伴うファイルシステムに関する。通常、書き込まれるべきデータは、直接永続ストレージに書き込まれる代わりに、メモリ内のバッファ領域に記憶されることになる。フラッシング動作は、現在バッファ領域に存在するデータを永続ストレージに書込みまたは記憶し、書き込んだデータと関連したバッファ領域をクリアすることによってバッファ領域をリフレッシュすることを含む。エネルギー効率または高応答性を達成するために、以下の方途、すなわちフラッシュされるべきデータの量が書込みエネルギー効率を決定する有力な要因の１つであるので、永続ストレージにフラッシュされるべきデータの量を削減すること、および／またはストレージＩ／Ｏ完了のアプリケーション待ち時間、換言すればアプリケーションが応答するようになるまでアプリケーションのユーザが待たなければならない時間の量を削減することが採用されることができるはずである。そのために、永続ストレージにフラッシュされる必要があるデータの量を削減するため、かつストレージＩ／Ｏ完了のアプリケーション待ち時間を削減するために、装置ランダムアクセスメモリ（RAM）上の大規模かつ長命なキャッシングが利用されることができる。
【０００５】
[0005]  ストレージにメモリ内書込みキャッシュをフラッシュするためのファイルシステムのポリシーはアプリケーション認識および／または適応があってよい。ポリシーは、アプリケーションのアクセス特性、電子装置とのユーザ対話の状態、および電子装置の状態の１つまたは複数に少なくとも部分的に基づいてよい。より詳細には、フラッシュされる用意ができたキャッシュされた書込み要求シーケンスのブロックが、アプリケーションのアクセス特性に従って決定されることができるはずである。加えて、フラッシングが装置エネルギー消費およびアプリケーション応答性に影響を与えないように、フラッシングタイミングが柔軟に選択されることができる。たとえば、アプリケーション応答性へのより少ない影響という結果になるだろうから、電子装置がアイドルであるときの状態がフラッシングを行うのに適切な時間であるだろう。
【０００６】
[0006]  この「発明の概要」は概念の抜粋を簡略形態で導入するために提供されることが理解されるべきである。概念は「発明を実施するための形態」でさらに下記される。この「発明の概要」は特許請求される主題の重要な特徴または本質的な特徴を特定するものとは意図されず、また特許請求される主題の範囲を限定するために使用されるものとも意図されない。
【０００７】
[0007]  利点は図面と併されて以下の詳細な説明から明らかになるだろう。
【０００８】
[0008]  本開示は例を通じて例証され、かつ同様の参照数字が同様の要素を示す添付の図に限定されない。
【図面の簡単な説明】
【０００９】
【図１】[0009]本明細書に記載される主題の実施形態が実装されることができるコンピューティング環境のブロック図を例示する。
【図２】[0010]ファイルシステムにおけるフラッシングを実装するためのコンポーネント例を図示する概略ブロック図を例示する。
【図３】[0011]データ古さが増すにつれてエネルギー向上可能性比率がどのように変動するかを図示するいくつかのアプリケーションのエネルギー向上可能性曲線を例示する。
【図４】[0012]本明細書に記載される主題の実施形態に従って電子装置のためのファイルシステムにおいてデータをフラッシュするための方法のフローチャートを例示する。
【図５】[0013]書込みが到来したときにメモリにデータをバッファする方法を示す例示的なフローチャートを例示する。
【図６】[0014]フラッシャがどのように本明細書に開示されるようなフラッシングポリシーに従って動作することができるかを示す例示的なフローチャートを例示する。
【図７】[0015]フラッシングに適切な間隔を予測するための単純状態機械モデルを例示する。
【図８】[0016]例示的な優先度ベースのスケジューリング機構を図示する。
【発明を実施するための形態】
【００１０】
[0017]  本明細書に記載される主題はここでいくつかの実施形態例を参照しつつ論じられることになる。これらの実施形態は、本明細書に記載される主題の範囲のいくらかの限定を示唆するよりむしろ、当業者が主題をよりよく理解し、したがって実装することを可能にする目的でのみ論じられると理解されるべきである。
【００１１】
[0018]  本明細書で使用される場合、用語「含む」およびその異体は「を含むが、これに限定されない」を意味するオープンな用語として読まれるべきである。用語「または」は文脈が別途明示しない限り「および／または」として読まれるべきである。用語「に基づく」は「に少なくとも部分的に基づく」として読まれるべきである。用語「１つの実施形態」および「実施形態」は「少なくとも１つの実施形態」として読まれるべきである。用語「別の実施形態」は「少なくとも１つの他の実施形態」として読まれるべきである。他の定義が、明示も黙示も、以下含まれてよい。
【００１２】
[0019]  図１は、記載される主題の１つまたは複数の実施形態が実装されることができるコンピューティング環境１００の例を例示する。様々な実施形態が多様な汎用または専用コンピューティング環境で実装されることができるように、コンピューティング環境１００は本明細書に記載される主題の使用または機能性の範囲に関していかなる限定も示唆するものとは意図されない。
【００１３】
[0020]  図１を参照すると、コンピューティング環境１００は、少なくとも１つの処理ユニット（またはプロセッサ）１１０およびメモリ１２０を含む。処理ユニット１１０はコンピュータ実行可能命令を実行し、かつ実または仮想プロセッサでよい。多重処理システムでは、複数の処理ユニットがコンピュータ実行可能命令を実行して処理能力を増加させる。メモリ１２０は、揮発性メモリ（たとえば、レジスタ、キャッシュ、RAM）、不揮発性メモリ（たとえば、ROM、EEPROM、フラッシュメモリ）、またはその２つのなんらかの組合せでよい。メモリ１２０は、ファイルシステムにおけるフラッシングのためのフラッシングモジュール１７０のための命令の少なくとも一部を記憶する。
【００１４】
[0021]  コンピューティング環境１００は追加的なコンポーネントまたは特徴を有してよい。図１に図示される例では、コンピューティング環境１００は、ストレージ１３０、１つまたは複数の入力装置１４０、１つまたは複数の出力装置１５０、および１つまたは複数の通信接続１６０を含む。バス、コントローラまたはネットワークなどの相互接続機構（図示せず）がコンピューティング環境１００のコンポーネントを相互接続する。典型的に、オペレーティングシステムソフトウェア（図示せず）がコンピューティング環境１００で実行する他のソフトウェアに動作環境を提供し、かつコンピューティング環境１００のコンポーネントの活動を調整する。
【００１５】
[0022]  ストレージ１３０は取り外し可能または非取り外し可能でよく、かつフラッシュドライブ、磁気ディスク、磁気テープもしくはカセット、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ、または情報を記憶するために使用されることができ、かつコンピューティング環境１００内でアクセスされることができる任意の他の媒体などのコンピュータ可読記憶媒体を含んでよい。ストレージ１３０は、フラッシングモジュール１７０のための命令の少なくとも一部を記憶してよい。
【００１６】
[0023]  フラッシングモジュール１７０は、すべて一般に「モジュール」または「機構」として本明細書で称されてよい完全にハードウェア実装、完全にソフトウェア実装（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）またはソフトウェアおよびハードウェア側面を組み合わせる実装の形態をとってよいことが留意されるべきである。さらには、フラッシングモジュール１７０の態様は、コンピュータ可読プログラム命令がそこに具象化される１つまたは複数のコンピュータ可読媒体で具象化されるコンピュータプログラム製品の形態をとってよい。フラッシングモジュール１７０のための命令は、完全にメモリ１２０に、完全にストレージ１３０に、または部分的にメモリ１２０にかつ部分的にメモリ１３０と通信状態にあるストレージ１３０に含まれてよい。
【００１７】
[0024]  入力装置１４０は様々な異なる入力装置の１つまたは複数でよい。たとえば、入力装置１４０は、マウス、キーボード、トラックボールなどといったユーザ装置を含んでよい。入力装置１４０は、言語認識、タッチおよびスタイラス認識、入力装置１４０と接触したおよび入力装置１４０に隣接したジェスチャの認識、エアジェスチャの認識、頭部および視標追跡、音声および言語認識、ユーザ脳活動を感知すること、ならびに機械知能などの１つまたは複数のナチュラルユーザインタフェース技術を実装してよい。他の例として、入力装置１４０は、スキャニング装置、ネットワークアダプタ、ＣＤ／ＤＶＤリーダ、またはコンピューティング環境１００への入力を提供する別の装置を含んでよい。出力装置１５０は、ディスプレイ、プリンタ、スピーカ、ＣＤ／ＤＶＤライタ、ネットワークアダプタ、またはコンピューティング環境１００からの出力を提供する別の装置でよい。入力装置１４０および出力装置１５０は、タッチスクリーン、仮想現実システム、ヘッドマウント装置を含むウェアラブルコンピューティング装置などの単一のシステムまたは装置に組み込まれてよい。
【００１８】
[0025]  通信接続１６０は、別のコンピューティングエンティティへの通信媒体にわたる通信を可能にする。付加的に、コンピューティング環境１００のコンポーネントの機能性は、単一のコンピューティングマシンに、または通信接続にわたって通信することができる複数のコンピューティングマシンに実装されてよい。したがって、コンピューティング環境１００は、ハンドヘルドコンピューティング装置、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置もしくは別の一般的なネットワークノードなどの１つまたは複数のリモートコンピューティング装置への論理接続を使用するネットワーク化環境で動作してよい。通信媒体は、データまたはコンピュータ実行可能命令もしくは要求などの情報を変調データ信号で伝達する。変調データ信号は、信号における情報をエンコードするような方式で設定または変更されるその特性の１つまたは複数を有する信号である。限定ではなく例として、通信媒体は、電気、光、ＲＦ、赤外線、音響もしくは他の搬送波で実装される有線または無線技術を含む。
【００１９】
[0026]  主題の実施形態はコンピュータ可読媒体の一般的な文脈で記載されることができ、それは記憶媒体または通信媒体でよい。コンピュータ可読記憶媒体はコンピューティング環境内でアクセスされることができる任意の利用可能な記憶媒体であるが、しかし用語コンピュータ可読記憶媒体は一時的伝播信号自体または他の信号自体を指さない。限定ではなく例として、コンピューティング環境１００については、コンピュータ可読記憶媒体はメモリ１２０、ストレージ１３０、およびその組合せを含む。
【００２０】
[0027]  主題の実施形態は、目標実または仮想プロセッサ上でコンピューティング環境で実行される、プログラムモジュールに含まれるものなどの、コンピュータ実行可能命令の一般的な文脈で記載されることができる。一般に、プログラムモジュールは、特定のタスクを行うかまたは特定の抽象データ型を実装するルーチン、プログラム、ライブラリ、オブジェクト、クラス、コンポーネント、データ構造などを含む。プログラムモジュールの機能性は、様々な実施形態において所望されるようにプログラムモジュール間で結合または分割されてよい。プログラムモジュールのためのコンピュータ実行可能命令はローカルまたは分散コンピューティング環境内で実行されてよい。分散コンピューティング環境では、プログラムモジュールは両ローカルおよびリモートコンピュータ記憶媒体に設けられてよい。
【００２１】
[0028]  本明細書に開示されるフラッシング機構はスマートフォンを含むがこれに限定されないポータブルまたはモバイル装置にとって有益であるだろうが、当業者は、フラッシング機構がＰＣなどの他の非モバイル装置に実装されることもできることを認識することができるはずである。したがって、上記したコンピューティング環境１００は、スマートフォン、タブレットコンピュータ、携帯情報端末（PDA）、ヘッドマウント装置を含むウェアラブルコンピューティング装置などといったモバイルまたはポータブル装置、ならびにデスクトップおよびサーバ、またはいくつかの小型固定装置などの非モバイル装置を含むがこれらに限定されない、様々なコンピューティング装置に実装されることができるはずである。例証かつ簡略化の目的で、それはスマートフォンなどの電子装置の文脈で下記される。
【００２２】
[0029]  以下の説明では、本明細書で使用される「データ整合性」はシステムクラッシュの存在下でデータバージョンを維持する態様を指す。より詳細には、時点整合性が使用され、これは永続ストレージにおけるデータが常に書込み履歴におけるまたは書込みキャッシュにおける時点でのデータに対応し、その結果その時間前の任意の書込みはストレージに達しており、その後の任意の書込みは達しないことを意味する。「データ古さ」は本明細書で使用される場合、現在のメモリ内データとストレージにおける永続データとの間の距離を意味する。直感的に、データ古さはシステムクラッシュ後に回復するためにどれくらいさかのぼるかである。換言すれば、データ古さは現在のメモリデータと永続ストレージにおける永続データとの間の距離である。データ古さは、時間またはバージョンなどの多くのメトリックによって測定されることができるはずである。この文脈では、データ古さは永続ストレージにまだフラッシュされていないデータの総量によって測定される。「データ耐久性」はコミットされるデータが永久に残存するだろうことを保証する性質である。耐久性は不揮発性または永続ストレージにメモリにおけるデータをフラッシュすることによって達成されることができる。本明細書で使用される「トランザクション」は１つまたは複数の個々の動作の集合を指す。
【００２３】
[0030]  前述したように、従来のファイルシステムは２つの方途を使用して、Ｉ／Ｏ性能を向上させつつ、データ古さを制限し、かつ整合性を保証する。第一に、ダーティビット、または永続メモリにまだ書き込まれていないビットが、小固定時間間隔後にメモリから永続ストレージに書き込まれる。ジャーナリングファイルシステムが、ジャーナルでなされるだろう変更を永続ストレージにコミットする前に、それらの経過を追う種類のディスクファイルシステムである。データ古さを制限し、かつ整合性を維持するために、通常のジャーナリングファイルシステムは周期的に永続ストレージにメモリ内書込みキャッシュをフラッシュするか、または各ファイル同期（sync）ごとにフラッシュを実施する。システムクラッシュまたは電力故障の場合には、そのようなファイルシステムはより迅速にオンラインに戻り、かつ破損されそうにない。たとえば、デフォルトのＬｉｎｕｘ（登録商標）  Ｅｘｔ４は５秒ごとにフラッシングをする、すなわちユーザはシステムクラッシュ後に多くとも５秒の履歴を失う。第二に、ファイル同期（「fsync」として示される）インタフェースが整合性を保証する方途を提供する。書込み動作がまず永続ストレージにおける主データベースファイルに影響することなく別々のログに出力され、次いでｆｓｙｎｃがログを通じて呼び出される。最後に、ログに記録した変更が主データベースファイルに変換される。
【００２４】
[0031]  しかしながら、従来のファイルシステムおよびファイル同期における周期的なフラッシングは、アプリケーション応答性およびエネルギー効率への著しい影響を有する。ｆｓｙｎｃを発行するときに、装置におけるアプリケーションは、すべてのデータがストレージに書き込まれるまで待たなければならない。頻繁なフラッシュは、その各々が著しいＣＰＵ利用を招くだろうが、システムを遅延させ、かつ直接または間接的に装置のエネルギー消費に相当影響を与えることがある。
【００２５】
[0032]  本明細書に記載される技術の様々な態様は一般に、電子装置のための適応フラッシングを伴うファイルシステムに向けられる。エネルギー効率または高応答性を達成するために、以下の方途、すなわち永続ストレージにフラッシュされるべきデータの量を削減すること、および／またはストレージＩ／Ｏ完了のアプリケーション待ち時間を削減することが採用されることができるはずである。
【００２６】
[0033]  書込み動作が読出し動作より多くのエネルギーを消費する一方、フラッシュされるべきデータの量が書込みエネルギー効率を決定する有力な要因であることが見いだされる。いくつかのデータがメモリに残り、二回以上上書きされれば、上書きされたデータはフラッシュされる必要はなく、これはエネルギー節減という結果になる。研究は、異なるアプリケーションが大きく異なるデータ読み書きアクセスパターンを有することを示す。たとえば、１つのアプリケーションがメモリにおける同じアドレスに頻繁に書き込むことがある一方、別のアプリケーションは常にメモリにおける異なるアドレスに書き込むことがある。そのような異なるデータ読み書きアクセスパターンは異なるエネルギー効率向上可能性を示すことができるはずである。換言すれば、フラッシングの用意ができたキャッシュされた書込み要求シーケンスのブロックが、アプリケーションの具体的な書込みパターンに基づいて決定されることができる。例として上記したアプリケーションを取り上げる。メモリにおける同じアドレスにデータを頻繁に書き込むアプリケーションに関しては、長期間の間に発生するこのアプリケーションと関連した書込み要求シーケンスが、フラッシングの用意ができたキャッシュされた書込み要求シーケンスのブロックとして決定されることができる。長期間の間に、書込み要求シーケンスに関する書き込まれたデータはメモリに保持されることができ、書込み要求シーケンスによって頻繁にアドレスされる場所におけるデータは頻繁に上書きされる。したがって、フラッシュされるべきデータはできるだけ多く削減されることができる。長期間の長さは、時間とともに変動するこのアプリケーションの書込みパターンによって決定されることができる。比較されるように、常にメモリにおける異なるアドレスに書き込むアプリケーションに関しては、このアプリケーションの書込みパターンによって示されるように上書きがほとんどなく、かつそれはフラッシュされるべきデータまで削減する空間をほとんど有しないので、任意の短期間の間に発生するこのアプリケーションと関連した書込み要求シーケンスが、フラッシングの用意ができたキャッシュされた書込み要求シーケンスのブロックとして決定されることができる。このようにして、異なるアプリケーションアクセス特性に基づいてフラッシュされるべきデータの量を削減し、それによってエネルギー効率を達成することが可能である。この点に関しては、フラッシング機構はアプリケーション適応性を有する。アプリケーションの具体的な書込みパターンに基づいてフラッシングの用意ができたキャッシュされた書込み要求シーケンスのブロックを決定することに関する詳細は、たとえば図３および図４におけるステップ４３０を参照しつつ後述されることになる。
【００２７】
[0034]  付加的に、整合性を保証するために多くの適切な機構が適用されることができるはずである。たとえば、トランザクション処理が書込みキャッシュに適用されることができるはずである。トランザクション処理は複数の個々の動作を単一の分割できないトランザクションに連結し、トランザクションにおけるすべての動作がエラーなしで完了されるか、またはそれらのいずれもそうではないことを確実にする。動作のいくつかが完了されるが、しかしその他が試みられるときにエラーが発生すれば、トランザクション処理システムはトランザクションの動作のすべてを、成功したものを含めて「ロールバック」し、それによってトランザクションのすべての形跡を消去し、システムをそれがトランザクションの処理が開始する前にあった整合した既知の状態に復元する。トランザクションのすべての動作が成功して完了されれば、トランザクションはシステムによってコミットされ、データファイルへのすべての変更が永続とされ、一旦これがなされると、トランザクションはロールバックされることができない。
【００２８】
[0035]  トランザクション処理機構は、データ整合性もエネルギー効率も提供するために上記したアプリケーション認識機構と組み合わされることができるはずである。いくつかの実装では、キャッシュされた書込み要求シーケンスなどの動作のトランザクションへの分割はアプリケーション認識がある、すなわちアプリケーションのデータ読み書きアクセスパターン次第であることができるはずである。
【００２９】
[0036]  別の態様では、フラッシングが装置エネルギー消費およびアプリケーション応答性に影響を与えないように、フラッシングタイミングが柔軟に選択されることができる。一般に、電子装置がアイドルであるとき、アプリケーション応答性へのより少ない影響を有するフラッシングをするのに適切なタイミングである。
【００３０】
[0037]  永続ストレージにフラッシュされる必要があるデータの量を削減するため、かつストレージＩ／Ｏ完了のアプリケーション待ち時間を削減するために、装置ランダムアクセスメモリ（RAM）上の大規模かつ長命なキャッシングが利用されることができる。いくつかの事例では、書込み性能およびエネルギー効率が以下の理由でデータ耐久性およびデータ古さより優先されてよい。第一に、現代の生産力でのランダムアクセスメモリ（RAM）は著しく増大した。たとえば、２ＧＢが今日の標準である。第二に、現代のスマートフォンはバッテリー電源を有する。この種類のバッテリバックアップＲＡＭ（BBRAM）は通常のＰＣまたはサーバ設定において信頼できると考えられる。第三に、大抵のアプリケーションデータは損失後にさえ回復可能である。たとえば、電子メールが失われるとしても、それは単にサーバからリロードされることができ、ソーシャルネットワーキングアプリケーション、デジタルマップなどといった他の普及しているアプリケーションに関しても同じことがあてはまる。したがって、メモリ損失の最悪の場合にさえ、データは単にリモートサーバからリロードされることができる。したがって、性能のためにデータ耐久性を犠牲にすること、すなわちエネルギー効率および応答性を向上させる結果としての可能性が相当であるならば、いくらか上昇するデータ古さの危険を冒すことが実行可能かつ有益であるだろう。
【００３１】
[0038]  一般に、従来のファイルシステムと比較して、本開示のいくつかの態様に係るファイルシステムは静的な小間隔またはファイル同期からフラッシュを解放し、データをかなり長くメモリに保持し、ストレージにメモリ内書込みキャッシュをフラッシュするためのそのポリシーはアプリケーション認識および適応がある。ポリシーは、アプリケーションのアクセス特性、電子装置とのユーザ対話の状態、および電子装置の状態の１つまたは複数に少なくとも部分的に基づく。より詳細には、キャッシュされたデータのどの部分がフラッシングの用意ができているか、すなわちフラッシュされる用意ができているキャッシュされた書込み要求シーケンスのブロックが、アプリケーションのアクセス特性に従って決定されることができるはずである。加えて、フラッシングがいつ行われるかを示すフラッシングタイミングは、電子装置のアプリケーションとのまたは電子装置とのユーザ入力対話に少なくとも部分的に基づいて柔軟に選択されることができる。さらに、フラッシュされる用意ができているデータユニットをスケジュールするための多重優先度スケジューリング機構が利用されることができるはずであり、それはアプリケーション間の公平性を確実にし、さらにフラッシング性能を向上させる。
【００３２】
[0039]  図２は、ファイルシステムにおけるフラッシングを実装するためのコンポーネント例を図示する概略ブロック図を例示する。本明細書に開示されるようなフラッシング機構は、現在既知であろうと将来開発されようと、任意の適切なファイルシステムを補足するためにそのファイルシステムと統合されることができる。いくつかの実施形態が以下になんらかのある種のコンポーネントと関連して論じられることになるが、これは本明細書に記載される主題の範囲のいかなる限定も示唆することなく例証の目的であるのみである。
【００３３】
[0040]  図２を参照すると、ファイルシステムにおけるフラッシングに関与する５つの主要コンポーネントが、バッファマネージャ２０２、バッファ２０３、フラッシャ２０４、ポリシーエンジン２０５およびファイルシステムストレージ２０６から成ってよい。
【００３４】
[0041]  バッファマネージャ２０２はデータのバッファリングを管理するように構成されてよい。バッファマネージャ２０２は、本明細書に開示されるようなアプリケーション認識機構を実装するために使用されることができる。バッファマネージャ２０２は、エネルギー向上機会を獲得するために、データをかなり長くバッファ２０３で管理および保持する。このために、バッファマネージャ２０２は、ポリシーエンジン２０５によって提供されるようなトランザクションポリシー２１２に従って、バッファされたデータをフラッシングの用意ができている区分に編成するように構成されることができる。この目的を達成するために、多くの適切な方式がバッファマネージャ２０２によって使用されることができる。いくつかの態様では、バッファマネージャ２０２はジャーナルコンポーネント２１６および逆マッピングコンポーネント２１８を備えてよい。
【００３５】
[0042]  ジャーナルコンポーネント２１６は、書込みログまたは先書きログとも呼ばれるジャーナルを維持するように構成されてよい。基本形式では、ジャーナルは、アプリケーションの書込み履歴を維持する、アプリケーションからのすべての書込み要求２０１の経時記録である。簡略のため、以下の説明では、ジャーナルコンポーネント２１６は略して「ジャーナル」と呼ばれることができる。ジャーナル２１６は、ファイルシステムによって割り当てられて、それがするだろう変更を事前に記録する特別な領域である。クラッシュ後は、回復は単に、ファイルシステムからジャーナル２１６を読み込み、ファイルシステムが再び整合するまでこのジャーナル２１６から変更を再生することを必要とするだけである。
【００３６】
[0043]  ジャーナル２１６は多くの適切な方式で実装されることができるはずである。いくつかのファイルシステムが、ジャーナルがまさしく通常ファイルとして増大し、縮小し、再割り当てされるようにする一方、他のものはファイルシステムがマウントされる間、移動またはサイズを変更しないと保証される連続した領域または隠しファイルにジャーナルを配置する。いくつかのファイルシステムは、ソリッドステートディスクまたはバッテリバックアップ不揮発性ＲＡＭなどの別の装置上の外部ジャーナルを許容してもよい。ジャーナルへの変更は追加的な冗長性のためにそれら自体ジャーナルに記録されてよいか、またはジャーナルが複数の物理ボリュームにわたって分散されて装置故障から保護してもよい。本開示は本明細書においてこの点に関しては限定を有しない。
【００３７】
[0044]  ジャーナル２１６におけるログエントリはそれぞれの書込み要求２０１に対応し、かつ書込み要求２０１と関連したバッファ２０３におけるそれぞれのアドレスを参照する。前述したように、キャッシュされた書込み要求シーケンスのブロックがフラッシングの用意ができているかどうかは、アプリケーションに特有に判定される、すなわちアプリケーション認識することができる。１つの実装では、ジャーナル２１６におけるログエントリは、ポリシーエンジン２０５によって提供されるようなトランザクションポリシー２１２に従って、フラッシングの用意ができているキャッシュされた書込み要求シーケンスのブロックを準備するように編成されることができるはずである。たとえば、ジャーナル２１６はアクティブまたは開いた区分および閉じた区分に分割されることができ、これがフラッシングの範囲を定める。アクティブ区分では、新しいログエントリが挿入されることができるはずであり、上書きおよび再順序付けなどのなんらかの性能向上手段が許容できる。この例では、アクティブ区分におけるログエントリはフラッシングの準備がされなくてよい。閉じた区分では、新しいログエントリは加えるのを許容されなくてよく、上書きおよび再順序付けなどの性能向上手段は禁止される。換言すれば、閉じた区分はキャッシュされたデータの異なるバージョンを保持するために使用される。ジャーナル２１６の閉じた区分におけるすべてのログエントリはフラッシングの用意ができており、ストレージにフラッシュするようスケジュールされるのを待つ。１つの実施形態において、ストレージは、ファイルシステムストレージ２０６などの永続ストレージを含む。いくつかの実施形態において、キャッシュされたデータのどの部分がフラッシングの用意ができているか、すなわち区分の閉じを判定することは、少なくとも部分的にアプリケーションのアクセス特性に基づく、より詳細にはアプリケーションのデータ読み書きアクセスパターンに基づくトランザクションポリシー２１２に従うことができるはずであり、それによって書込みスループットおよびエネルギー効率を向上させる。トランザクションポリシー２１２の詳細は後に詳述されることになる。
【００３８】
[0045]  付加的に、整合性を保証するために多くの適切な機構が適用されることができるはずである。たとえば、トランザクション処理が書込みキャッシュに適用されることができるはずである。トランザクション処理機構は、データ整合性もエネルギー効率も提供するために上記したアプリケーション認識機構と組み合わされることができるはずである。そのような実施形態において、キャッシュされた書込み要求シーケンスなどの動作のトランザクションへの分割はアプリケーション認識がある、すなわちアプリケーションのデータ読み書きアクセスパターン次第であることができるはずである。したがって、ジャーナル２１６における区分はトランザクションと呼ばれることもできる。
【００３９】
[0046]  認識されることができるように、フラッシュされるのを待ついくつかの閉じた区分またはトランザクションがあるかもしれない。換言すれば、ジャーナル２１６はキャッシュされたページの異なるバージョンを有することができるはずである。例証かつ簡略化の目的で、この情報を捕捉するために、バージョン別キャッシュトランザクション（VCT）が使用されてよい。通常、ＶＣＴはその存続時間に３つの状態を経験する。すなわち、それが開いているまたはアクティブであるとき、それはアクティブ区分におけるエントリを包含し、かつ新たに追加されるエントリを継続的に含むことができる；それが閉じているとき、その終了位置は固定され、すべてのそのエントリは閉じた区分に配置される；およびそれがコミットされるとき、フラッシャ２０４はそれを選び、すべてのそのエントリを永続ストレージに原子的に書き込む。その後、トランザクションおよびそのエントリはファイルシステムによって削除される。上書きおよび再順序付けなどのなんらかの性能向上手段は単一のトランザクションの範囲内で許容されるのみである。フラッシャ２０４がコミットされたトランザクションの耐久性および原子性を保証することになるので、これらの改善はいかなる不整合な状態も残さないだろう。
【００４０】
[0047]  ジャーナル２１６は、円形アレイ、リストまたはなんらかの他の形態を含むがこれに限定されない、多くの適切な形態として具象化されることができる。いくつかの実施形態において、各アプリケーションはそれ自身のジャーナルを有してよく、したがってアプリケーションのためのジャーナルは単一のアクティブ区分を有してよい。ジャーナル２１６が円形アレイとして具象化されると、新しいログエントリはジャーナルの終端の単一のアクティブ区分に追加されることができる。いくつかの実装では、円形アレイの末尾はスピンロックによって保護されて、新しいエントリの処理時間を削減することができる。加えて、円形アレイの先頭は、末尾が成長して先頭に達したときのみ書込み要求を延期するミューテックスによって保護されることができるはずである。ミューテックスは、任意の時間に、１つのスレッドのみがミューテックスに対応するオブジェクト（この例では、円形アレイの先頭）にアクセスすることができることを保証するフラグである。
【００４１】
[0048]  ジャーナル２１６はいくつかの他のデータ構造を埋め込んで、追加的な改善を提供することもできるはずである。例として、ｋｏｂｊｅｃｔ構造（ファイルシステム階層の基本構築ブロック）が埋め込まれることができるはずであり、その結果ファイルシステムはユーザ空間インタフェースを／ｓｙｓディレクトリ下のファイルとしてエクスポートすることができる。少なくとも２つの利益がそのようなｋｏｂｊｅｃｔ構造によって達成されることができるはずである。第一に、ユーザは各ジャーナルの基本性質を容易に確認および設定することができる。第二に、それは、ジャーナル２１６の先頭および末尾を保護するために２つのロックが使用されているためにフラッシングと追加との間の区別をすることによって並列書込みをサポートする。
【００４２】
[0049]  逆マッピングコンポーネント２１８は、バッファ２０３の参照されるキャッシュユニットからジャーナル２１６内のログエントリへの逆マッピングを維持するように構成されることができる。逆マッピングは２つの目的で使用されることができるはずである。第一に、バッファ２０３からキャッシュユニットにおけるデータを削除するときに、この逆マッピングは、対応するエントリの場所を突き止め、それを無効としてマークするために使用されることができるはずである。第二に、新しい書込みが到来したときに、それは、目標キャッシュユニットがエントリによって参照されているかどうかを確認し、そうであれば、どのエントリがそれを参照するかを判定するために使用されることができる。この情報はバッファされたデータを編成するためにバッファマネージャ２０２によって使用されることができる。例示的な処理は後述されることになる。
【００４３】
[0050]  逆マッピングコンポーネント２１８は多くの適切な形態で実装されることができる。それを実装する１つの手法はカスタマイズされたハッシュテーブルを含み、それはシステム全体のロックの代わりに各バケットごとにリーダ−ライタロックを使用する。エントリと関連したページは、ページキャッシュがそれらを排除しないように増加されるその＿ｃｏｕｎｔフィールドを有する。これは、メモリ空間が不足する前にファイルシステムがページを解放して、メモリ不足問題を回避しなければならないことも意味する。逆マッピングを実装する別の手法は、ページ構造に参照ポインタを加えることである。構造体ページはすでに多くのフィールドが詰められている（たとえば、３２ビット変数に２４＋フラグが存在する）ので、この手法は可変サイズを拡大することを必要とする。
【００４４】
[0051]  バッファ２０３は、ファイルデータをメモリに記憶し、かつユーザ要求に応対する主要な形態である。バッファ２０３は、揮発性メモリにおいてファイルデータの一部分をホストしてＩ／Ｏ性能を向上させるために使用される。バッファ２０３は、ダイナミックＲＡＭ（DRAM）およびスタティックＲＡＭ（SRAM）を含むがこれらに限定されない任意の種類の揮発性メモリによって実装されることができる。いくつかの実施形態において、キャッシュは、書き込まれるべきデータをバッファするために使用されることができる。通常、オペレーティングシステム（OS）は大抵、たとえばＬｉｎｕｘ（登録商標）システムで、メモリをページで管理する。例証かつ簡略化の目的で、用語「ページキャッシュ」が以降バッファ２０３を表すために使用されることになり、キャッシュページはキャッシュにおける管理されたユニットを指す。しかしながら、当業者は、メモリがページ以外の任意の他の適切なユニットで管理されることができることを認識することができるはずであり、本開示は本明細書においてこの点に関しては限定を有しない。ページキャッシュ２０３は、ＯＳおよび／または他のマウントされたファイルシステムと共有される任意の現存のページキャッシュ、または特に本明細書に開示されるフラッシング機構に割り当てられるページキャッシュであることができるはずである。
【００４５】
[0052]  キャッシュページが書き込まれた、または変更された場合、それはダーティとしてマークされることになり、これはキャッシュページが変更されており、かつストレージにまだ保存されていないことを示す。大容量のページキャッシュは長命なメモリキャッシングをサポートし、それによってエネルギー効率およびアプリケーション応答性を向上させるための機会を提供する利点を有する。
【００４６】
[0053]  フラッシャ２０４は、揮発性メモリと不揮発性ストレージとの間のデータフローを管理する通信機構である。フラッシャ２０４は２つの責任を有してよい。第一に、それは、ストレージへのデータの永続記憶を管理する基礎をなすストレージコンポーネントを呼び出す。第二に、ファイルシステムがロードされるときに、フラッシャ２０４は目標パーティションを確認し、任意のデータ不整合の回復を試みる。
【００４７】
[0054]  ページキャッシュ２０３におけるいくつかのキャッシュページがダーティであるとき、フラッシャ２０４は、ファイルシステムストレージ２０６などの永続ストレージにページデータを書き戻す責任を負う。いくつかの実施形態において、フラッシャ２０４は、ポリシーエンジン２０５によって提供されるようなフラッシングポリシー２１４に従ってフラッシングをする。より詳細には、フラッシングポリシー２１４によって指示されて、フラッシャ２０４はなんらかの適切なフラッシングタイミングで、たとえば電子装置がアイドルであるときにフラッシングを行う。さらに、フラッシングポリシー２１４の制御下で、フラッシャ２０４は、ジャーナル２１６を参照しつつフラッシングの用意ができているページキャッシュ２０３におけるキャッシュされたデータをスケジュールする。
【００４８】
[0055]  フラッシャ２０４は任意の適切なストレージコンポーネントに基づいて、任意のトランザクションを原子的にフラッシュすることができるはずである。様々なフラッシュデータ形式がフラッシャ２０４に関して使用されることができるはずであり、本開示はこの点に関しては限定を有しない。たとえば、Ｅｘｔ４およびＢｔｒｆｓなどの多くのファイルシステムのストレージ管理コンポーネントが、フラッシャ２０４をサポートするために容易に採用されることができる。
【００４９】
[0056]  ポリシーエンジン２０５は、フラッシングのための様々なポリシーを提供するために使用される。ポリシーエンジン２０５は拡張可能なフレームワークでよいので、様々な代替または追加のポリシーが使用されてよい。いくつかの実装では、ポリシーエンジン２０５はバッファマネージャ２０２にトランザクションポリシー２１２を提供して、バッファされたデータをフラッシングの用意ができている区分に編成する、すなわちキャッシュされたデータのどの部分がフラッシングの用意をすることができるかを判定する。換言すれば、トランザクションポリシー２１２は、いつアクティブ区分またはトランザクションを閉じるべきかを判定する。トランザクションポリシー２１２はアプリケーション特有であることができ、これはアプリケーションのデータ読み書きアクセスパターンに基づいている。
【００５０】
[0057]  異なるアプリケーションは大きく異なるデータ読み書きアクセスパターンを有する。たとえば、１つのアプリケーションがメモリにおける同じアドレスまたは同じキャッシュページに頻繁に書き込むことがある一方、別のアプリケーションは常にメモリにおける異なるアドレスまたはキャッシュページに書き込むことがある。そのような異なるデータ読み書きアクセスパターンは異なるエネルギー効率向上可能性を示すことができるはずである。上書きされたデータがエネルギー効率を向上させることができる程度を捕捉するため、多くのメトリックがエネルギー効率向上可能性を表すために使用されることができるはずである。例として、上書きからのエネルギー効率向上可能性を表すためにエネルギー向上可能性比率ｒのメトリックが使用され、それはｒ＝ｏ／ｓと定義され、式中ｓはページキャッシュにおけるダーティデータの量を示すデータ古さであり、ｏは最後のフラッシュ以来上書きされたデータの累積総量である。
【００５１】
[0058]  図３は、データ古さが増すにつれてエネルギー向上可能性比率がどのように変動するかを図示するいくつかのアプリケーションのエネルギー向上可能性曲線を例示する。図３において、Ｘ軸はデータ古さｓを表し、その範囲は、１つの図にすべての曲線を描くためにアプリケーション間で統一される。範囲値が、データスケールの感覚のためだけにアプリケーション名と並んで注記される。Ｙ軸はエネルギー向上可能性比率ｒを表す。４つの曲線が図３に図示され、ここで曲線３０１はゲームアプリケーションを表し、曲線３０２はデジタルマップアプリケーションを表し、曲線３０３はブラウザアプリケーションを表し、曲線３０４はソーシャルネットワーキングアプリケーションを表す。
【００５２】
[0059]  図３から分かるように、異なるアプリケーションは大きく異なる曲線の形状を有し、それらのエネルギー向上可能性の大きな差を示す。たとえば、いくつかの曲線（たとえば、曲線３０１、３０３）はかなり平坦である一方、他（たとえば、曲線３０２、３０４）は単調に増加している、または緩やかなピークを有する。そのような多様性はこれらのアプリケーションに対する異なるエネルギー向上機会を意味する。たとえば、曲線（たとえば、曲線３０１）にピークを伴うアプリケーションに関しては、以後エネルギー効率向上可能性が低下するので、アクティブ区分またはトランザクションを閉じる１つの例示的な適切な機会はそのピークである。増加曲線（たとえば曲線３０２、３０４）を伴うアプリケーションに関しては、増加傾向が穏やかになる点が閉じるのによい機会であるが、これはその点を越えると、エネルギー効率向上可能性は少ししか増加しない一方、古いデータがページキャッシュにおけるますます多くの空間を占め続けるからである。平坦な曲線（たとえば、曲線３０３）を伴うアプリケーションに関しては、機会は非常に融通がきく。
【００５３】
[0060]  したがって、トランザクションポリシー２１２はアプリケーション認識があり、かつアプリケーションのデータ読み書きアクセスパターンに基づくことができる。いくつかの実装では、トランザクションポリシー２１２はたとえば上記したエネルギー向上可能性曲線を使用して、ページキャッシュ２０３におけるフラッシュされていないデータの現在量を基に、将来上書きから可能な向上の程度を推定する。換言すれば、トランザクションポリシー２１２の特徴は、可能な限りエネルギー向上曲線のピークの場所を突き止めることである。
【００５４】
[0061]  加えて、電子装置におけるアプリケーションデータパスの分離が、アプリケーション認識トランザクションポリシー２１２の実行を可能にする。ＰＣまたはサーバ上とは異なり、モバイル装置ユーザはめったにアプリケーションがどこにインストールされるかを選んだり、または装置上のディレクトリ間で直接ファイルを移動させたりせず、これは交差アプリパスの整合性問題を回避する。そのようなモバイル装置上のアプリケーションのデータパスは、ファイルシステムがパスを通じてアプリケーションを区別し、かつ異なるアプリケーションのためのポリシーを自動的に向上させることを可能にする規定を有する。いくつかの実施形態において、単一のアプリケーションによって影響されるすべてのデータパスは、アプリケーション適応性の基本ユニットとして設定されることができる。
【００５５】
[0062]  ポリシーエンジン２０５はまた、フラッシャ２０４にフラッシングポリシー２１４を提供して、適切なフラッシングタイミングを決定し、かつフラッシングの用意ができているキャッシュされたデータをスケジュールする。換言すれば、フラッシングポリシー２１４は、いつどの区分またはトランザクションをフラッシュするべきかを決める。
【００５６】
[0063]  フラッシングポリシー２１４は、いつフラッシュするべきかを決めるタイミングポリシーを備えることができるはずである。フラッシングをトリガすることができる多くの条件がある。いくつかの態様では、タイミングポリシーは、装置のアプリケーションとのまたは装置とのユーザ入力対話に少なくとも部分的に基づいてフラッシングタイミングを決定することができるはずである。他の態様では、フラッシングタイミングポリシーは、装置がいつ目下アイドル状態にあるかに基づくことができるはずである。装置はいくつかの異なる状態、すなわちスタンバイ、アイドルおよびビジーを有してよい。「スタンバイ」は装置の画面がオフにされ、かつ装置がサスペンド条件に入るときを指し、「アイドル」は画面がオンであり、かつ装置がアクティブであるが、ユーザ操作がないかまたはユーザ操作がより少ない、たとえば所定の閾値より低いことを意味し、「ビジー」は画面がオンであり、かつ装置がアクティブであり、ユーザ操作が頻繁、たとえば所定の閾値より高いことを意味する。たとえば、ユーザが対話中に画面内容を読む、または熟考するとき、そのような間隔はフラッシングのための有益な時間を表してよい。そのような間隔は多くの適切な方式で予測されることができるはずである。たとえば、１つの実装では、装置のアプリケーションとのまたは装置とのユーザ入力対話の活動度が所定の閾値より低いときに、装置がアイドルであり、フラッシングのための有益な時間であることが決定されることができる。タイミングポリシーのための例示的な実装は後述されることになる。
【００５７】
[0064]  当業者は、適切な時間であるかどうかに関わらずフラッシングをトリガするいくつかの他の条件、たとえばページキャッシュがあまりに大きくなる、およびメモリ使用量があまりに高いときがあることを理解することができるはずである。任意選択により、装置がスタンバイにあるとき、アプリケーション応答性への影響がより少ないまたはないためにフラッシングが行われることもできる。それらの条件は上記したようにユーザ対話ベースの条件と組み合わされることができる。
【００５８】
[0065]  フラッシングポリシー２１４は、フラッシングの準備がされているまたは用意ができているキャッシュされたデータ中のどの区分またはトランザクションをフラッシュするかを決めるスケジューリングポリシーをさらに備えることができるはずである。
【００５９】
[0066]  通常、アプリケーション内で、トランザクションが順番にフラッシュされることが好ましいだろう。そこで１つの実装では、スケジューリングポリシーに対する一般的な考慮点は、所与のアイドル間隔の間にできるだけ多くのトランザクションをフラッシュすることである。様々な適切なスケジューリング機構がスケジューリングポリシーを実装するために使用されることができるはずである。複数のアプリケーションからの未完了のトランザクションを考えるとき、アプリケーション間の公平性を確実にし、さらにフラッシング性能を向上させるために、多重優先度スケジューリング機構が利用されることができるはずである。スケジューリングポリシーの実装例は後述されることになる。
【００６０】
[0067]  ファイルシステムストレージ２０６はファイルデータを永久に記憶するために使用される。ストレージ２０６は、プログラマブルＲＯＭ（PROM）、電気的書替え可能ＲＯＭ（EAROM）、消去可能プログラマブルＲＯＭ（EPROM）および電気的消去可能プログラマブルＲＯＭ（EEPROM）などの様々な読出し専用メモリ（ROM）、フラッシュメモリ、ディスクなどを含むがこれらに限定されない任意の種類の不揮発性メモリによって実装されることができる。上述したように、フラッシャ２０４が特定のストレージデータ形式と組み合わされていないので、ファイルシステムストレージ２０６は任意のデータ形式をもつ任意の永続ストレージであることができるはずである。
【００６１】
[0068]  いくつかの実施形態において、各アプリケーションはそれ自身のジャーナルまたは書込みログ２１６を有することができるはずである一方、逆マッピングコンポーネント２１８、ポリシーエンジン２０５およびフラッシャ２０４はファイルシステムにおける複数のアプリケーションの様々なインスタンス間で共有されることができるはずである。
【００６２】
[0069]  以上このように、本明細書に開示されるようなフラッシング機構を実装するための例示的なコンポーネントを記載した。当業者は、上記説明が本明細書に記載される主題の範囲のいかなる限定も示唆することなく例証の目的に過ぎず、追加または代替のコンポーネントも可能であることを認識することができるはずである。
【００６３】
[0070]  図４は、本明細書に記載される主題の実施形態に従って電子装置のためのファイルシステムにおいてデータをフラッシュするための方法のフローチャートを例示する。ステップが必ずしも図４に示される順序で行われるわけではないことが理解されるべきである。その代わりに、それらのステップは任意の他の適切な順序で、または並列に行われてよい。
【００６４】
[0071]  方法４００は、書込み要求（たとえば、図２における書込み要求２０１）が受信されるステップ４１０で始められる。書込み要求の各々は装置のアプリケーションと関連づけられることができる。書込み要求は、書き込まれるべき目標ページ、書込み要求と関連した書き込まれるべきデータ、書き込まれるべきデータのサイズなどといった、この動作によって必要とされるような情報を含むことができる。
【００６５】
[0072]  次いで、ステップ４２０で、書き込まれるべきデータは、図２に図示されるようなページキャッシュ２０３などの揮発性メモリにバッファされることができるはずである。データは、エネルギー効率機会を獲得するためにページキャッシュでより長く生きるように促される。ストレージに書き込むためのページキャッシュ２０３で変更されたページは「ダーティ」としてマークされる。図２に図示されるようなジャーナル２１６などのジャーナルは、アプリケーションの書込み履歴を記録するために使用されることができる。図５は、書込みが到来したときにメモリにデータをバッファする方法を示すフローチャートを例示するが、それは後述されることになる。
【００６６】
[0073]  ステップ４３０で、キャッシュされたまたはバッファされたデータは、フラッシングの用意ができているブロックに編成される。キャッシュされたデータの編成は、図２に図示されるように、ポリシーエンジン２０５によって提供されるトランザクションポリシー２１２の制御下でバッファマネージャ２０２によって行われる。
【００６７】
[0074]  前記したように、トランザクションポリシー２１２は、キャッシュされたデータのどの部分がフラッシングの用意をすることができるかを判定するために使用される。トランザクションポリシー２１２はアプリケーションのデータ読み書きアクセスパターンに少なくとも部分的に基づく。いくつかの実施形態において、エネルギー向上比率ｒ曲線（図３に図示されるような）は、アプリケーションの異なるエネルギー効率向上可能性を示すために使用される。直観的に、トランザクションを閉じる最善の点は最も高いｒをもつ点である。したがって、トランザクションポリシー２１２の目的は、現在のアクティブ区分またはトランザクションを終えるまたは閉じるために、可能な限りエネルギー向上最適点に接近する適切な書込み要求を見いだすことである。各新しい書込み要求はエネルギー向上比率曲線における点を表すことができるはずである。そのようなアクティブトランザクションを閉じるのに適切な書込み要求または点を見いだすか、または推定するために、様々な曲線フィッティング法、線形フィッティングまたは高次非線形フィッティングなどの様々な適切な方式が適用されることができる。
【００６８】
[0075]  いくつかの実施形態において、到来する書込み要求または点が現在のアクティブトランザクションを閉じるのに適切な書込み要求とみなされるべきかどうかを推定するために、オンライン法が使用されることができるはずである。将来の書込み要求は未知であり、曲線の変動が局所最適点を選ぶことに至ることができるので、１つの実装では、変動を軽減するためにスライディングウィンドウ内の線形フィッティングが使用される。たとえば、線形フィッティング法は、最新のｋ個の点を記憶し、線をフィットし、線の勾配を介してピークを判断することができるはずである。
【００６９】
[0076]  適切な書込み要求を推定するための方法は書込みごとに行われるので、ＣＰＵオーバーヘッドおよび結果としてのエネルギーコストを削減するために、その計算複雑性は単純であるべきである。なんらかの調整が線形フィッティング法になされることができるはずである。たとえば、増分バージョンが通常の線形フィッティング式から得られることができるはずである。それらは各新しい点ごとに逐次更新され、計算は少数の基本算術演算のみを必要とする。このフィッティング法の効果を制御するために２つの要因が使用されてよい。第１は履歴ｋの長さである。ｋが小さいほどフィッティング法を変動により高感度にすることになる一方、ｋが大きいほど検出遅延が長いという結果になる。遅延を制限するために、第２の要因ｇが調整されることができる。フィッティング法は勾配がｇを下回るまで待つが、それは必ずしもゼロであるわけではない。
【００７０】
[0077]  ステップ４４０で、フラッシャ２０４は、図２に図示されるように、ポリシーエンジン２０５によって提供されるフラッシングポリシー２１４に従って、メモリにおけるデータ、たとえばフラッシングの用意ができているページキャッシュ２０３を永続ストレージ、たとえばファイルシステムストレージ２０６にフラッシュすることができる。
【００７１】
[0078]  フラッシングポリシー２１４は、フラッシャ２０４に、適切なフラッシングタイミングを決定し、かつフラッシングの用意ができているキャッシュされたデータをスケジュールするように指示する。ステップ４４０についてのより詳細な動作は図６を参照しつつ後述されることになる。
【００７２】
[0079]  図５は、書込みが到来したときにメモリにデータをバッファする方法を示す例示的なフローチャートを例示する。図５に示される例では、整合性を保証するためにトランザクション処理が利用される。当業者は、多くの適当な方法がデータをバッファするために使用されることができるはずであり、これは本明細書に記載される主題の範囲のいかなる限定も示唆することなく例証の目的であるのみであることを認識することができるはずである。また、ステップが必ずしも図５に示される順序で行われるわけではないことが理解されるべきである。その代わりに、それらのステップは任意の他の適切な順序で、または並列に行われてよい。
【００７３】
[0080]  方法５００は、書込み要求が受信されるステップ５１０で始められる。書込み要求は装置のアプリケーションと関連づけられることができる。書込み要求は、書き込まれるべき目標ページ、書込み要求と関連した書き込まれるべきデータ、書き込まれるべきデータのサイズなどといった、この動作によって必要とされるような情報を含むことができる。
【００７４】
[0081]  １つの実施形態において、ステップ５２０で、受信した書込み要求と関連した目標ページがアプリケーションと関連したジャーナル２１６内のログエントリによって参照されているかどうかが、たとえばページキャッシュ２０３におけるダーティページからジャーナル２１６におけるログエントリへの逆マッピングに基づいて確認される。
【００７５】
[0082]  目標ページがジャーナル２１６における任意のログエントリによって参照されなければ、これはアプリケーションがジャーナル２１６外で新しいページに書き込むことを意味し、次いでステップ５６０で、新しいログエントリがジャーナル２１６における現在のアクティブ区分またはトランザクションに追加されることができるはずである。一方、新しい逆マッピングが生成されてこの新しいログエントリと関連することができる。
【００７６】
[0083]  目標ページがジャーナル２１６におけるログエントリによって参照されれば、これはアプリケーションがダーティページに書き込むことを意味し、次いで方法５００はステップ５３０に進むことができる。
【００７７】
[0084]  １つの実施形態において、ステップ５３０で、ログエントリがアクティブまたは開いたトランザクションにあるかどうかが確認される。ログエントリがアクティブトランザクションにあることに応じて、これは上書きのための良好な機会、および目標ページがいかなる閉じたトランザクションによっても保護されないことを意味し、次いでステップ５４０で、目標キャッシュページが直接上書きまたは変更されることができる。新しいログエントリを追加する必要はない。
【００７８】
[0085]  ログエントリが閉じたトランザクションにあることに応じて、これはアプリケーションがなんらかのトランザクション内に封じられ、かつ上書きから保護されるダーティページ上に書き込むことを意味し、次いで１つの実施形態においてステップ５５０で、ファイルシステムは目標ページ上に書込み時にコピーする（COW）。詳細には、この目標ページは書き込まれる前に複製され、ログエントリは原本コピーと関連するように変更される。次いで、複製した目標ページは書込み要求に従って変更されることができ、新しいログエントリがジャーナル２１６における現在のアクティブトランザクションに追加される。一方、新しい逆マッピングが生成されて目標ページの変更したコピーをこの新しいログエントリと関連づけることができる。
【００７９】
[0086]  図６は、フラッシャ、たとえば図２におけるフラッシャ２０４がどのように本明細書に開示されるようなフラッシングポリシー２１４に従って動作することができるかを示す例示的なフローチャートを例示する。一般に、フラッシングポリシー２１４は、応答性に配慮したフラッシングのための時間を見いだすために、装置のユーザが装置をアクティブに操作しないと予期される時間間隔を予測するタイミングポリシーを備える。フラッシングポリシー２１４は、とりわけ複数のアプリケーションと関連した複数のジャーナルがフラッシングの用意ができた１つまたは複数の閉じたトランザクションを有するときに、フラッシングの用意ができたものの中のどのトランザクションをフラッシュするかを決めるスケジューリングポリシーをさらに備えてよい。
【００８０】
[0087]  方法６００は、装置のアプリケーションとのまたは装置とのユーザ対話が監視されるステップ６１０で始められる。ユーザ入力対話は、装置次第で、任意の種類のユーザ操作であることができるはずである。たとえば、タッチスクリーン装置に関しては、ユーザ入力対話は、タップ、ダブルタップ、ある方向に向けたスワイプ、回転、ピンチ、アンピンチ、フリック、多指タップまたはスクロールなどを含むがこれに限定されない、すべての形態のスクリーンタッチジェスチャであることができるはずである。いくつかの実施形態において、いくつかのイベントを１つの論理操作に組み合わせるためにフィルタが使用されるが、これはいくつかの論理ユーザ操作が、スワイプハンドジェスチャなどの、間隔が小さい、たとえば所定の閾値より小さい複数の画面イベントを招くからである。
【００８１】
[0088]  ユーザ入力対話の監視は、ユーザ操作がいつ発生するか、ユーザ操作がどれくらいしばしば発生するか、などを含むことができるはずである。監視に基づいて、フラッシングのための間隔を予測するために、最終のｋ個の測定間隔の中からの最終最小モデル（LMM、最小を選ぶ）または最終平均モデル（LAM、平均を選ぶ）などの単純ストローマン解法を含むがこれらに限定されない、様々な対話モデルが使用されることができるはずである。
【００８２】
[0089]  図７は、フラッシングに適切な間隔を予測するための単純状態機械モデルを例示する。当業者は、図７における状態機械モデルが本明細書に記載される主題の範囲のいかなる限定も示唆することなく例証の目的のための例に過ぎないことを認識することができるはずである。多くの他の適切な状態機械がフラッシングのための間隔を予測するように設計されることができる。
【００８３】
[0090]  スマートフォンなどの現代のモバイル装置のユーザが通常、長短間隔間で切り替わることが認識されることができる。たとえば、ソーシャルネットワーキングアプリケーション上でニュースフィードを読むときに、ユーザは興味深いものにより長くとどまりそれを読む以前にいくつかのポストを急いでざっと読むことがある。有限状態機械モデルは上記認識に基づく。
【００８４】
[0091]  図７に図示されるように、２つの中央状態、ユーザが短い間隔で操作する高対話状態７０１およびユーザが長い間隔で操作する低対話状態７０２がある。２つの状態の各々は別々の最近の間隔の履歴Ａ［ｌ．．．ｋ］を維持し、平均値ｐを使用して次の間隔を予測する。それらの各々はタイマｔも所有し、それはある値に達するとタイムアウトをトリガし、状態遷移ごとにゼロにリセットされる。これらのフィールドはそれぞれ２つの状態に対するｌまたはｈで注釈をつけられる。たとえば、図７に図示されるように、高対話状態７０１は間隔の履歴Ａｈ［ｌ．．．ｋｈ］およびタイマｔｈを維持し、低対話状態７０２は間隔の履歴Ａｌ［ｌ．．．ｋｌ］およびタイマｔｌを維持する。２つの追加的な中間状態、より高対話状態７０３およびより低対話状態７０４が、間隔予測を増減する補助のために使用される。
【００８５】
[0092]  図７に図示されるような状態機械モデルでは、エッジまたは矢印は１つの状態から別の状態への遷移を示す。各矢印はその遷移をトリガする入力およびなされるべきアクションでラベルをつけられる。図７に図示される状態図から分かるように、状態機械は次のように動く。すなわち、高対話状態７０１（略して「h」状態）にとどまる間、円形矢印７１１によって示されるように、到来するイベントがユーザ操作であれば、それはループすることになる。しかしながら、ユーザ操作がタイムアウトイベントＴ前に到来しなければ、機械はユーザが長い間隔を開始するかもしれないと仮定し、そのためそれは低対話状態７０２（略して「l」状態）に変化する。この遷移は矢印７１２によって示される。「ｌ」状態７０２では、予測時間ｐｌがユーザ対話なしで成功して経過すれば、状態機械はユーザ操作を待つより低対話状態７０４に入り、それによって長い間隔予測を増加させる。この遷移は矢印７１３によって示される。ユーザ操作が予測時間前であるが、しかしτより後に到来すれば、ユーザは依然長い間隔で操作すると考えられるが、しかし長い間隔予測は減少されるべきであるので、それはより高対話状態７０３になる。この遷移は矢印７１４によって示される。そうでなければ、ユーザ操作は非常に速く（τ前に）到来するで、ユーザは短い間隔に切り替わると推定され、次いで状態は高対話状態７０１に直接設定される。この遷移は矢印７１５によって示される。他の動作は図７に図示されるような状態図から明らかなはずであり、したがってその詳細な説明はここで省略される。
【００８６】
[0093]  状態図から、フラッシングを行う２つの機会があることが分かり、それはそれぞれ矢印７１２および矢印７１６によって示される。フラッシングのための間隔の長さは平均値ｐによって予測される。
【００８７】
[0094]  図６へ戻る。ステップ６２０で、ステップ６１０での監視および採用した間隔予測モデル（たとえば、図７に図示されるような状態機械モデル）に少なくとも部分的に基づいてフラッシングをするべきか否かが判定される。換言すれば、装置がアイドル状態にあるか、すなわち画面がオンであり、かつ装置がアクティブであるが、ユーザ操作がないかまたはユーザ操作がより少ない、たとえば所定の閾値より低いかどうかが判定される。装置がアイドルであれば、それはフラッシングのためのよい時間を意味し、次いで方法６００はステップ６３０に進み、フラッシングを行うことが決められる。そうでなければ、方法６００はステップ６１０に戻って、ユーザ入力対話を監視することができる。
【００８８】
[0095]  前述したように、フラッシングをトリガすることができるいくつかの他の条件がある。たとえば、いくつかの他の条件が考慮されることができるはずであり、それらは、たとえばページキャッシュがあまりに大きくなる、およびメモリ使用量があまりに高いときに、適切な時間であるかどうかに関わらずフラッシングをトリガする。それらの条件は上記したようにユーザ対話ベースの条件と組み合わされることができる。
【００８９】
[0096]  フラッシングを行うと決め、ステップ６４０で、フラッシングのための間隔の長さが予測されることができる。例証の目的であるとはいえ、ステップ６４０がステップ６３０後に示され、当業者は、様々な対話モデルに基づいて適切な間隔が発生するかどうかを判定するときに、間隔の長さは予測または推定されることができることを認識することができるはずである。いくつかの実施形態において、間隔を予測するために図７に図示されるような有限状態機械モデルが使用され、そこでは間隔の長さを予測するために平均値ｐが使用される。
【００９０】
[0097]  次いで、ステップ６５０で、図２に図示されるように、ポリシーエンジン２０５によって提供されるようなスケジューリングポリシーに従って、フラッシングの用意ができているページキャッシュにおけるデータがスケジュールされることができる。
【００９１】
[0098]  一般に、スケジューリングポリシーは、フラッシングの準備がされているまたは用意ができているキャッシュされたデータ中のどの区分またはトランザクションをフラッシュするかを決める。通常、アプリケーション内で、トランザクションは順番にフラッシュされなければならない。そこで、スケジューリングポリシーに対する一般的な考慮点は、所与のアイドル間隔の間にできるだけ多くのトランザクションをフラッシュすることである。様々な適切なスケジューリング機構がスケジューリングポリシーを実装するために使用されることができるはずである。複数のアプリケーションからの未完了のトランザクションを考えるとき、アプリケーション間の公平性を確実にし、さらにフラッシング性能を向上させるために、多重優先度スケジューリング機構が利用されることができるはずである。そのような実施形態のための典型的なシナリオは、ユーザが音楽ラジオを聞きつつアプリケーションと対話しており、バックグラウンド電子メールまたはニュースサービスがプッシュメッセージを継続的に受信するということであることができる。
【００９２】
[0099]  スケジューリングポリシーはトランザクションの１つまたは複数の属性に少なくとも部分的に基づくことができ、その結果適当なトランザクションが公平かつエネルギー効率良い方途で選ばれることができる。トランザクションの属性は、トランザクションの状態、トランザクションの長さ、トランザクションの親和性、およびトランザクションの年齢の１つまたは複数を含む。
【００９３】
[00100]  トランザクションの状態はアクティブ状態および閉じた状態を含む。前記したように、閉じたトランザクションのみがフラッシングのためにスケジュールされることができるはずである。
【００９４】
[00101]  トランザクションの長さはトランザクションに対してフラッシュするべきページ数を指す。長さに基づいて、１つのトランザクションをフラッシュするために必要とされる時間が推定されることができ、それによってトランザクションが現在の予測間隔にフィットして、アプリケーション応答性に影響するいかなる起こりうる衝突、たとえばフラッシュ動作が対話ユーザ操作とオーバーラップすることも回避することができるかどうかが判断されることができる。
【００９５】
[00102]  トランザクションの親和性は、２つ以上のトランザクションが同じアプリケーションに帰属するかどうかを示す。同じアプリケーションのトランザクションは、それらが共にフラッシュされれば、それらは併合されて、したがってエネルギーを節約することができるので、親和性を有するものである。換言すれば、親和性を有する２つ以上の連続したトランザクションは、エネルギー向上範囲を拡大するためにフラッシング前に１つに併合されることができる。
【００９６】
[00103]  トランザクションの年齢は、トランザクションが任意の間隔にフィットされなかったために以前にスキップされた回数によって表されることができる。公平性のため、いくつかのアプリケーショントランザクションがあまりに長い間フラッシュされていないままであることは望ましくない。
【００９７】
[00104]  トランザクションをトランザクションの上記属性に基づいてフラッシュされるようスケジュールするために、様々なスケジューリング方法が使用されることができる。１つの手法は優先度ベースのスケジューリング方法である。たとえば、以下の４つの優先度考慮点が使用されることができ、ここで数が低いほど高い優先度を意味する。
【００９８】
[00105]  考慮点１（トランザクション親和性）：トランザクションが選ばれるときはいつでも、同じアプリケーションの他のトランザクションが残りより優先される。簡略のため、以下スケジューリングの単位として、アプリケーションが直接使用される。アプリケーションが選ばれるときを除き、アプリケーションの先頭のもの以外の他のトランザクションは考慮されないことに留意されたい。待機アプリケーションを編成するために、様々な適切なデータ構造が採用されることができる。図８は、待機アプリケーションを編成するための例示的なデータ構造を図示する。
【００９９】
[00106]  図８に図示されるように、３つの候補待ち行列、高緊急待ち行列８０１、低緊急待ち行列８０２および通常待ち行列８０３、ならびに非候補待ち行列８０４がある。待ち行列における各フレームはアプリケーションを表す。３つの候補待ち行列８０１、８０２および８０３は、同様の年齢のトランザクションを共にバッチ処理する方途を形成する。アプリケーションが待ち行列でスキップされるときはいつでも、それは待ち行列から除去され、より緊急の待ち行列があれば、そこに配置される。
【０１００】
[00107]  考慮点２（トランザクション年齢）：３つの候補待ち行列８０１、８０２および８０３に関しては、より緊急の待ち行列からのアプリケーションが、より緊急でない待ち行列からのアプリケーションより優先される。候補待ち行列に実行可能な選択がないときは、高緊急待ち行列における最短のものがフラッシュするように選択されることができるはずである。
【０１０１】
[00108]  考慮点３（トランザクション長）：候補待ち行列におけるアプリケーションは、その先頭トランザクションの長さが利用可能な間隔より短いときにのみ、フラッシュするよう実行可能である。
【０１０２】
[00109]  考慮点４（待ち行列補充）：任意の待ち行列におけるアプリケーションが閉じたトランザクションを有するとき、それは通常待ち行列に加えられる。すべての３つの候補待ち行列が空であるとき、非候補待ち行列におけるすべてのアプリケーションが通常待ち行列へ移動する。
【０１０３】
[00110]  以上このように、電子装置のための適応フラッシングを伴うファイルシステムを記載した。ファイルシステムはデータをかなり長くメモリに保持し、ストレージにメモリ内書込みキャッシュをフラッシュするためのそのポリシーはアプリケーション認識および適応がある。１つの態様では、キャッシュされたデータのどの部分がフラッシングの用意ができているかがアプリケーションのアクセス特性に従って判定されることができるはずであり、これはアプリケーション適応性を反映する。別の態様では、フラッシングタイミングは、電子装置のアプリケーションとのまたは電子装置とのユーザ入力対話に少なくとも部分的に基づいて柔軟に選択されることができ、これはユーザ適応性を反映する。さらに、フラッシュされる用意ができているデータユニットをスケジュールするための多重優先度スケジューリング機構が利用されることができるはずであり、それはアプリケーション間の公平性を確実にし、さらにフラッシング性能を向上させる。
【０１０４】
[00111]  主題が構造的特徴および／または方法論的行為に特有の言語で記載されたとはいえ、添付の請求項に定められる主題が上記した具体的な特徴または行為に必ずしも限定されるわけではないことが理解されるべきである。むしろ、上記した具体的な特徴および行為は請求項を実装する形態例として開示される。
【０１０５】
[00112]  本開示は様々な変更および代替構成の余地があるが、その一定の例示された実施形態が図面に図示され、かつ詳細に上記された。しかしながら、本開示を開示した具体的な形態に限定しようとする意図はなく、逆に本発明の趣旨および範囲内に収まるすべての変更、代替構成および等価物を包含することを意図するものであることが理解されるべきである。上記した実施形態のいずれの態様も、記載されるその他の実施形態のいずれかの態様と組み合わされて、求められる効果を失うことなくさらなる実施形態を形成することができる。
【図１】
0006527577.tif 000002
【図２】
0006527577.tif 000003
【図３】
0006527577.tif 000004
【図４】
0006527577.tif 000005
【図５】
0006527577.tif 000006
【図６】
0006527577.tif 000007
【図７】
0006527577.tif 000008
【図８】
0006527577.tif 000009